#begin
Earlier we mentioned we would take another look at over analyzing the requirements. The following section of the chapter is all about the specification trap. But first, what exactly is a specification. Well, David and Andrew say that a specification is a requirement broken down to the point where a developer’s skill can take over. It’s and act of communication between de business and de technical domain. It removes any ambiguity of the, sometimes abstract requirement to be codified. A specification can be used for the initial implementation and as a record for future maintenance and enhancement. So, it’s quite a responsibility to write proper specifications.
And I fully agree. Specifications are really important to any project. A project will probably be unsuccessful without specifications. I’ve seen this before when, just because we are doing to vague ripoff of an agile methodology, and ‘big upfront design’ is bad practice, no design whatsoever was done, no specifications, nothing. Well you can predict how that project went.
The pendulum can also swing the other way; sometimes designers don’t know when to stop. They think every little detail must be pinned down so there is not room for ambiguity, creativity and financial surprises.
David and Andrew say that over specification is a mistake for many reasons. First of all, they say it’s very naive to think that a specification can capture any minute detail of a requirement. Even when you do, there is always the problem of human interpretation of both the requirement and the specification. Second, the expressive power of language will most likely limit you in the communication of the specification. Whoa, that’s deep right!? I mean, I know that english is a pretty, let’s say shallow, language compared to some if not all the languages spoken in Asia. I don’t know about the details but I’ve heard linguists explain this before. But language itself, and most likely english can limit you in the transfer of information. This is why legal documents written by lawyers are often bending the language in weird obscure ways. To combat this I’ll recommend you guys a great book. It’s called communication patterns by Jacqui Read. It’s a great book about how to communicate in a professional manner and how to transfer information effectively. She explains about all kinds of communication like visual and accessible communication for vision impaired people.
The third reason why over specification is a bad idea is what David and Andrew call the straitjacket effect haha. An overly specified design leaves no room for interpretation and creativity for the developer. It takes away a lot of what makes programming fun. Additionally, as all developers everywhere know; the nitty gritty details can never be designed up-front. There are just too many little down to the metal choices to be made. We don’t want to kneel for the architect in his ivory tower. That’s a common analogy in our industry but it can certainly be true.
As Pragmatic Programmers we will view requirements gathering, design and implementation thereof as different steps in the global process; the delivery of a high quality system. There should not be any silos in this process. One process must flow into the next in a smooth and seamless manner without artificial boundaries. David and Andrew say: ”a healthy development process encourages feedback from implementation and testing into the specification process.” And I couldn’t agree more.
They also raise an important nuance and that is the that the depth of a specification is correlated with the type of system you are writing. There is a difference between writing software for your mom’s gardening service website as there is for software running on pacemakers or hardware that is launched into space. It’s relative. Be sure to keep that in mind while in the specification process.
So when you see your team being suck in the specification trap, try to break them out. At some point you really need to start coding. Get your team into prototyping or consider a tracer bullet approach.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments