We Have Met the Enemy, and They Is Us

"We Have Met the Enemy, and They Is Us"

Weinberg [1995] notes that change can indeed be insidious. In attempting to understand and explore sources of requirements change, he compared the known requirements of the system at the end of one project to those known at the beginning of the project. In so doing, he discovered a variety of sources of requirements change. Some were "official" external change, representing customer requests made through the appropriate channels of communications, but many were surprisingly " unofficial ," or what Weinberg calls "requirements leakage." These included

• Enhancements mentioned by distributors who had been overheard by programmers at a sales convention

• Direct customer requests to programmers

• Mistakes that had been made and shipped and had to be supported

• Hardware features that didn't get in or didn't work

• Knee-jerk change-of-scope reactions to competitors

• Functionality inserted by programmers with "careful consideration" of what's good for the customer

• Programmers' "Easter Eggs"

Each of these sources may contribute only a small amount of change, but in accumulation, unofficial sources contributed up to half of the total scope of one project! In other words, half of the total work product of the system was invested in requirements leakage, or requirements that entered the system without visibility to the team members responsible for managing the schedule, budget, and quality criteria.

In one project, half of the total work product of the system was invested in requirements leakage!

How can a project manager accommodate change of this type and still meet the schedule and quality criteria? It can't be done! In order to have a reasonable probability of success, requirements leakage must be stopped or at least reduced to manageable levels.

Programmers' Easter Eggs

Programmers' Easter Eggs are a particularly pathological form of requirements leakage. An Easter Egg is a hidden behavior built into the system for debugging purposes, for "the fun of it," or, occasionally, for worse motives. In our experience, Easter Eggs are extremely dangerous, and programmers must know that inserting them is completely unacceptable and that doing so will subject the offenders to dire consequences. Two painfully true cases follow.

• A large military simulation system took a long time to execute, so the programmers built into the system a background game of Battleship to amuse themselves during the simulation. Unfortunately, they never took it out, nor did its existence appear on any of the verification and validation activities or reports . When it was discovered, the customer, having lost confidence in the subcontractor, canceled the entire program: a multimillion-dollar loss to the subcontractor and a serious detriment to future business opportunities.

• A junior programmer contributing to the development of a shrink-wrapped software tool amused himself by building in derogatory user error messages in early stubs of error-recovery code. One such message was accidentally left in and discovered by a customer in a formal product training session. The software had to be repaired and re-released on an unplanned basis, causing the loss of critical team-weeks to the company.