The very highest form of specification in software development practice is a direct conversation.  When a customer works directly with a software engineer on the same product at the same time, something amazing happens.  The need for traceability matrices, requirements documents, demos and other formalities fade into the background and the development process moves at a very high speed.

Pete McBreen explained in the book “Software Craftsmanship: The New Imperative ” that since software is primarily an intellectual activity, moving information from one person to another is problematic.  Each transfer of information from person to person requires a translation.  Each translation produces a new opportunity for error.  The fewer translations information has to go through the less error possibilities there are.  Not only that, the fewer people that the information has to be passed to, the less work is done translating and less time is spent over all.  That is why conversation is such a high form of specification.  It moves the information need for development directly from the customer to the engineer making the software.

In practice, it works something like this:

1. An engineer takes a story and starts to work on it
2. A detail-oriented question arises
3. Since the customer is right there, the engineer asks the customer
4. The customer explains how the system should work
5. The engineer builds the answer right into the system and shows them.

That’s all there is to it.  This process repeats with all of the developers all day.  It really doesn’t matter that the story was missing detail, because the customer was able to fill in the gaps.

It is important to note that the conversational form of specification is only a partial solution.  The problem is that if these specifications are not recorded in some external form such as programmer tests, user story tests, or written scenarios, they will be forgotten and may not be re-assessed as changes are made to the system over time.  Not having the written form of validation, will most likely lead to your software’s value diminishing significantly over time.  It is possible, however to have a highly-successful product created without doing much more than just making stories, having conversations, and using test-driven development.  I plan to write much more about test-driven development in the days to come.

The reason that programmer tests alone may not be sufficient is that the programmer tests only the software from the perspective of the programmer.  If you work in an organization that needs to be thinking and preserving the requirements from a customer perspective, you will probably want to start developing scenarios or user story tests as soon as possible.

If you develop software using conversations only and then changes are made to the software, how can you be sure that the old conversations are still true?  If you review the software somehow, then you can know, but if you have forgotten the conversations you have no way of reviewing how the software should be working now and your software is at risk of loosing value.