How to Fail at Software Development |
||||||||
14. Is the written design document treated with respect? |
||||||||
| Score from 0 to 5 | ||||||||
| Score 0 if the design document answers everybody’s questions. The software development taking place is based on detailed and exact documentation that specifies the purpose and design of the entire project. Nobody would work without such a document because it would be silly to be working away on something and not know what it is. If you can't describe it in a document, you certainly can't program it into a computer. If your design document is exciting, fun to read, and is always clear about everything, score 0 while you’re still awake waiting for the Tooth Fairy and Santa Claus. Score at least 1 if the design document contains most of what you need, and what it contains is correct. However, from time to time you find an oversight. But the information found in the document is fundamentally sound, and it is possible to interpret the missing parts by understanding the parts that are there. This is the normal case for a good design specification. Something is almost always missing—but you should be able to figure out what it would have been. Score at least 2 if you have a reasonable document, but at the same time you find that some of the oversights leave medium-sized holes that can only be filled in by making decisions that require designing software. When you look for something in the design document, you’re not surprised when you don’t find it. And, when you do find it, it has some pieces missing that have to be filled in. Score at least 3 if the design document contains big holes that have to be filled in. In documents of this type you will also find that some of the parts are clear and well written, but they don’t make sense in terms of software. You not only have to fill in the blanks but you occasionally find something that has to be thrown out. Working with this sort of document will cause programmers to start making up processes and then adding their new inventions to the design. A project like this will only end if it has been very well staffed. Score at least 4 if not only are large parts of the design missing, and other parts are ambiguous, but from time to time the darned document disagrees with itself. In one place it will tell you one way to implement something, and in another place it will tell you another. This is the result of using the monkeys-and-typewriters approach to writing design documents. Some undetermined number of monkeys divided up the job of designing the software, then each one went to its own tree and did the actual typing. To keep things moving at a nice brisk pace, they didn’t communicate with one another on such trivial matters as document content. Score 5 if the design document causes prolonged laughter during lunch breaks. In the beginning the programmers will try to follow the document. After a while they just use it as an outline and try to fill in the blanks. Finally they wind up doing whatever they want to do and just keep the document around for its entertainment value. If you’ve got one of these super silly documents you may consider having it bound and sell copies of it as a book. You could call the book, “How to Fail at Software Design.” |
||||||||