How to Fail at Software Development

2. What happens to ideas for changes?

Score 0 if the only changes accepted the few determined to be absolutely necessary to version 1.0. An update is made to the written specification and the schedule is extended accordingly. The schedule must almost always be extended because a change almost never takes anything out.

Score at least 2 if some bad change ideas slip through. The ideas should all be screened and their numbers kept down, but some real doozies can slip in under the gate. If one gets in, so do others. This is never a one-time event.

Score at least 3 if all the changes that come from outside are accepted. Some of the ideas that come from within the project may be rejected, but if it comes from the user, it must be done. Your project has this problem if some guy wanders in from the sales department and says, “Hey. I’ve got an idea,” and he gets a response like, “Sure. We’ll put that in for you.”

Score at least 4 if all the changes that come from both inside and outside the project are included. This is the sort of situation that pushes the actual ending date of the project out beyond a usable time. If this is happening, it’s still possible for the project to be rescued because the constant adjustment of the schedule will require moments of sanity on the part of management, and the silliest of the changes will be removed.

However, if the changes come rolling in and the schedule is not being adjusted to reflect the additional work, you have to score 5. The project may never end. It will go on and on with changes coming in through every portal until the thing is so far behind schedule and has become so insignificant nobody pays attention to it any more. Then the changes will stop coming because nobody cares.

Chapters 2 and 13 of How to Fail at Software Development describe how to set yourself up to receive as many changes as possible, and Chapter 3 explains how these changes can be used in the most destructive way.