Thursday, April 4, 2013

Code+tests == specification?

Have you worked together with Agile enthusiasts (or fanatics) in the past? If the answer is yes, you might know what I want to talk about.
One of the core concepts of the agile movement is "working code over comprehensive documentation". I strongly agree with it. Many of us know of projects failed or missed deadlines because of the big up front specification and design. It usually does not work if requirements can change during the design or implementation phase. Unfortunately many agile enthusiasts simply state that time spent preparing the specification is useless, as the code and test suite themselves replace specification. I think they try to put the cart behind the horse.
First, without enough time spent on up front specification and design, the project usually ends up with a sub-optimal architecture, ad hoc solutions and endless refactoring. The more large scale the project is, the greater the chance of failure or at least missing deadlines.
Second, you need a specification to make sure you build the right product. Yes, you can show the result of each iteration to the customer, but his/her opinion it not a proof. He/she might not be aware of other things than the UI and a subset of the functional requirements. Without a written specification you cannot prove anything. Sure, you can test the implementation, but unit tests can only prove the presence of bugs, they cannot prove their absence. Even Test-Driven Development won't help you, since tests may be incomplete or may contain bugs and the code reflects this. The only way to prove correctness is to test each and every feature based on the written specification. This can be automated by creating an acceptance test suite, but first you need a specification to write acceptance tests.
Years before, I was attended to a conference organized by a local computer science society. One of the presenters talked about a case study of a military-grade project done by using Extreme Programming. The presenter was proud of the fact that they only used post-it notes created on iteration planning meetings. I was curious if they had to verify the resulting system and how could they do it without a specification, only based on these post-it notes? Unfortunately the session ran out of time, and the presenter left the room, leave me no chance to talk him.
To recap, in most of the cases, skipping the specification step is not something that can be done without negative consequences. We are agile enough if we spend some time for creating a specification and a conceptual architecture up front. This is an overhead, of course, but it'll pays back in the long run.
Post a Comment