Recap

The contents of this chapter have provoked more heated discussion than the rest of the book combined. Software developers and their managers are very uncomfortable with the hard line I take on commitments. They keep trying to explain to me that "software development is different."

Well, sorry, folks, but I just don't believe it. Every area of human endeavor has risk and uncertainty. Every project ever undertaken has some new or novel element in it. All projects have schedules that are too short and resources that are inadequate. Just ask your brethren in other domains. You are not that special.

It's not that I'm unsympathetic, you understand. Software does have some peculiar problems. The most vicious of these is management's misconception that large changes can be made at the last minute through the magic of changing just one line of code. This is not reality, but fantasy. More likely, when a problem is found, it will take major rework, just like in any other area where architecture governs the result.

Another frequently heard argument is that all ambitious software development projects have new and unique aspects that make their scheduling difficult and their deliveries uncertain, that it is more fundamentally an R&D activity. I have two counterarguments.

• First, if one uses a process that constrains and contains the R&D part of the project to an "elaboration" phase (as in the Rational Unified Process), this activity can be monitored, controlled, and kept from becoming "unbounded." Risk-targeted iterative development helps a lot here.

• Second, I will wager that most software development projects are late not because the R&D activity, which after all is often but a small component of the total, was late. No, more often what happens is the project is late because of poor execution on the routine parts of the job, and then the R&D activity becomes the scapegoat. It is easier to get forgiveness for screwing up the rocket science part of the project than it is to get absolution for messing up the blocking and tackling.

What I want to crush, once and for all, is the notion that what makes software different is what makes it impossible to hold software people to their commitments. That idea is both wrong and dangerous. It gives everyone the ultimate excuse for not performing, and is at the root of a great deal of what makes software development an unprofessional activity today. Professionals take their commitments seriously, and there is always accountability. This concept is crucial both for the individuals who practice software engineering and the profession as a whole.

There is also a strong directive here for managers: Do not bully people into commitments that you want but they don't really believe are realistic. You may win the bullying war, but it will be a small consolation down the road when the commitment is not met. The only commitments that have a reasonable chance of being met are those where the compromise position between the manager and the developer makes both of them only slightly uncomfortable at the outset.

In the next chapter, I move on to a topic that is never discussed openly. This is the delicate subject of compensation. Why don't we find more help in this area? Look for some interesting new ideas on this in the pages that follow.