- Excellent specifications = Very refined exhaustive view of future potential features
- Good unit tests = Very refined exhaustive view of actual features
- If you write detailed specifications, you’ll have to implement them as unit tests anyways.
- Hence : you specify twice.
- Worst : you need more budget to maintain your specifications because it’s a static Word document.
- On the contrary : my unit tests evolves with the real feature. Otherwise it crashes my integration host (remember last episode ?)
It’s The Economy Stupid !
So what is the real goal of specifications ?
Specifications in a static form are not useful to actually write the code. They are to conduct dialogs like this :
Client : Hi, this software is nothing close to what I expected.
You : Hi client. I don’t care that’s what you approved. Look, it’s here in the specifications.
It’s In The Process
Specifications work like that :
- The client describes roughly what he wants to a specification writer.
- This person works for 10 days trying to describe in a very precise fashion what could happen in the finished product.
- He then hands it the project manager who estimates costs and delays and assign this task to a developer.
- The developer starts implementing a feature. He looks at the specs and starts to code. He develops the main classes. Maybe he is already late because the PM was wrong in his estimations.
- Then he stops and goes strait to the person who wrote the specs (if he’s still here) and asks for details.
- Then goes back to his workbench, and does some manual tests.
- Then back to the spec-person for more precision, then back to his code, and manul tests.
- The integration tester gets the feature and does some tests.
- Then back to the dev for corrections.
- Back and forth again and again.
At the end the client has a feature that doesn’t look like the specs nor his wish.
It’s In Agile
That’s why the Agile thinking appeared. It’s like Toyota Lean Thinking applied to software production. The goal is to progress by little bits and be sure the client makes regular corrections along the road.
The Agile + Unit Tests process would be :
- Client writes a user story (a light specification of a feature according to his real need)
- He hands it to a developer for estimations and costs. They agree on priorities if budget is limited.
- Developer writes unit tests to embrace a lot of aspects of the future feature. He
canmust ask details to the client directly.
- Developer writes the code.
- Developer runs its unit tests and correct what’s wrong.
- Integration tester does some remarks (a lot less than before) based on his knowledge of the business need.
- Developer makes some corrections.
- Back to integration and then deliver.
In this process you see that specification-writer and project manager are not very important. But that’s another debate.
Specifications are really a monument in some company.
A very few people could refrain from throwing a chair in your face when you’re showing them the useless of detailed specifications. But if you want to deliver great software in time, you should learn to crouch.
- Try to find some old specifications,
- Then compare them to the real feature,
- Then see how your users actually use it.
- Is there a real gap ? How much did you spend in specifications that could have been spent in client collaboration and unit testing ?
For the developers out there
Do you need long detailed specifications to start coding or to maintain a software ? What’s the minimum you need ?