Programmers in the real world will tell you that specs aren’t worth the paper they are written on. They are half-baked informal descriptions that are too abstract to be understood by the users, and too imprecise to be useful to the programmers. They are full of internal inconsistencies and factual errors, because there is no way to test them. They are obsolete the day they are published, because it is too difficult to rewrite them as the system becomes better understood. Things are no better with the other standard commodities of development: project plans, schedules, cost estimates, and documentation.Jonathan Edwards, The Currency of Development
How do we make it easy to rewrite functional specifications? Some cultures try to solve the problem with command-and-control ("thou shalt not make a code change without an accompanying tech spec").
What I've observed is that all the information we want is out there in emails, PowerPoint decks, screen shots, and documents. And that's just the stuff produced by customers/analysts/product managers. What about the comments in the source code and the source code control system that describe how the changes close a specific bug or implementa specific feature?
Everything's fragmented and gets more and more unwieldy as projects move forward.Using examples as the central communication idea is just part of the solution. We need to make it easy to write examples and read them. We need to track the history of changes. And we need to tie the examples closely to tasks and releases.