Documentation = Evidence: Avoid!

One of the problems with the Waterfall Method is the huge amount of documentation that it requires. This is also true for the process for generating documentation called the Salmon Method (see The Parable Of The Yakisobi) which results in a huge quantity of documentation, but as the output of the process, rather than as the input. Nobody has yet hit on the idea of writing a requirements document for a document, but surely it's only a matter of bureaucratic time.

The problems with documentation are:

• It's hard to write
• It's open to interpretation
• It's hard to keep up to date with changing requirements
• It can be used in evidence against you

When you compare this to the principles of Agile, you will see why documentation is a problem. Agile principles:

• Be young
• Be foolish
• but, be happy
• Change and change often
• Don't allow the promises of the past to affect the promises you make in the future
• Never stay in the same opinion long enough to have to deliver on it

Therefore, you need some good reasons for why no document should ever be written. Here are some top excuses:

• Requirements - these change, so we'll have a meeting and take individual requirements and write their names on cards - those cards will symbolise the requirement and then we'll make up the rest
• User documentation - we will write software so easy to use that no user documentation will be required. Or, we will write software with so few actual features that a user manual would be very empty and so may as well be forgotten.
• Coding standard - we'll use pairing to enforce a coding style, or as it is sometimes known, a stalemate of conflicting opinion
• Architecture overview - we will not keep any record of how the system works, the people who have worked on it will be a living record; they will pair with others who will then magically know through the process of osmosis, and the circle of life will be complete. This will fail if we shuffle the teams around or several people resign in disgust in the same month. But if that happens, then we'll abandon the projects they worked on.
• Long-term plan - by the time any long term plan could have been written up we'll have changed it. That's the Agile way. To write a long-term plan would be like painting the Forth Road Bridge, and why would a software company want to do painting?

With these tools you can, effectively, block any record of what the software is meant to do, actually does, how it works, where it's going and whether it has a future. Your position will be, unlike the jobs of the developers, totally safe.