Some time ago I and some colleagues started an open source project to create an application to register the Foosball games we play at work, in order to look at statistics and see which teams win the most games. As we wanted to learn more about Specification by Example we decided to try and drive the development with the process described by Gojko in his book. Even though we haven’t done much more than specifying a couple of features, we got a couple of lessons (re)learned from it.
The first lesson is that you won’t save time in the specification process by reducing the number of participants. We tried to hold a specification workshop with only two participants. After working thoroughly on our specification, making them self-explaining with examples, we validated our effort by getting the other developers to proof read them. The criteria that they where good enough was that the developers should be able to describe the requirements without any help from us. Our requirements where accepted without any changes, and we where satisfied with a job well done... until a couple of days later when some of the developers wanted to implement the features. The lengthy discussions we now had, where similar to the ones we had in the workshop just a few days earlier, but now with a different people. It was important issues to clarify, but we could have clarified them earlier. Luckily nothing was implemented which depended on these requirements, as is often the case in larger projects. That would have made it even more wasteful. My lesson out of this is: You don’t save time by reducing the number of participants in specification workshops, you will only end up with the same discussions over again, and at a later time in the development cycle.
The second lesson I (re)learned, is that creating good specifications is hard work. It is so easy to underestimate the time it takes to conceive and formulate specifications that are unambiguous and easy to read/understand. To specify two requirements with examples, we used almost two hours. That's an hour per requirement!! Obviously some time was spent getting our heads around the relative new way of writing specs(with examples that is) and settling for the right granularity for this application. But I remember sitting in the workshop looking at my watch and thinking that we should be more effective! And I honestly think that if this hadn’t been a project on our spare time with a focus on learning Specification by example, we would soon be cutting corners to produce more specifications in shorter time. And that is really bad! The sad thing is that this is a likely scenario in many projects, but you never see the costs of cutting these corners until development is well under way.The cost is often put down to development costs, and thus not showing the real cost of specification work. We all know that uncovering mistakes or misunderstandings in the requirements at this stage is many times as expensive as doing it ”right” in the first place, but until we accept that creating good specifications is hard work we will continue to waste time and money.
