It’s Mathematical
- 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 ?
Money.
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.
Todo
- 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 ?
It might be that “Unit tests actually ARE the specifications” as understood by the developer and functional or acceptance tests are the specifications as understood by the customer… ;o)
What do you think? My point of view is that only the customer can validate the results and decide that a feature is “done”.
You are right there is a distinction between dev validation and customer validation.
It’s true only customer can validate a feature. And in this case unit tests are not used. But the developer don’t need precise detailed specifications. He just needs to be sure to integrate what the customer wants. That’s the subtle distinction.
The customer won’t look at the specifications to validate what he wants ! He already knows. So nobody needs detailed specs. Just talking to each other, prototyping and ensuring software quality through unit tests and integration tests.
Thanks for your comment that makes me precise my thoughts ! Cheers.
Saying unit tests are specifications is wrong, I think. Unit tests will verify that the API implementation does what it is intended to do, but nothing assures that its intent meets the needs of the customer. Unit tests do not capture the voice of the customer and are not something that customers will provide feedback on. If the developer who writes the tests doesn’t understand what the customer wants, the unit tests will verify the wrong thing. Also, two competing implementations may provide the customer with what they want, but each fail each others unit tests.
I think user stories expressed as BDD features in english (ala Cucumber) are the specifications. Customers can actually read and validate that these are what they want. These supplement, but do not replace unit tests. The BDD feature tests verify the code does what the customer wants, and the unit tests verify the API works as it was developed to do.
You are right.
In the case I was thinking of when writing the article, my client actually wanted an API.
I totally agree.
BTW thanks for pointing me to Cumcumber. Great stuff.
I don’t completely agree with you :
– you will never cover your whole code with unit tests (especially interfaces with other applications), so a part of the specs would be in the unit test, the other part in the specifications
– specifications will be read by many people : coder, but also project manager, test manager, IMO (for agreement), and the people in charge of the user training : I promise that only the coders will be able to read them
The project manager is also supposed to have an overview of the whole application, as he is responsible for its content and that it is consistent (features not duplicated, or coders not implementing features based on datas that are supposed to be correct when they are not, etc). This can be discussed but I am convinced the project manager has an important role to play in the definition of the product.
Imo, your opinion might be applicable in a product management (anyway, specifications of a product are never up to date and nobody ever reads them), but for a project, especially a large one involving many people, unit tests can’t completely replace specifications.
Hi Julien,
yes, my position is a little provocative on purpose. But you said it yourself :
On the other hand, unit tests are read by developers and most of all : launched. This makes them the only up to date documentation of a project. Specification for other humans (devs are not), may be translated from this tests.
Of course you can’t have a 100% of your spec in unit test. But you can have much more than usual. This won’t replace a kind of specification-user manual. But for limit technical algorithms the best is unit tests, not static word document.