Extreme Programming Values - Courage

Background

Traditional development processes are based on Boehm's Cost of Change Curve, which stipulates that the earlier in the development cycle that a defect or change is caught and addressed, the less it costs to fix it. As a result, these processes are very model and document-centric, attempting to specify all aspects of a system in gory detail before any code is written. After all, models and documents are easier to change than code.

These processes created a culture in which changes must be rigorously controlled in order to prevent costs from skyrocketing, and for delivery schedules to be maintained. Requirements would be locked, and a sign-off would occur. Functional and detailed designs would be locked, and sign-off would occur. Code would be written according to the designs, would be frozen, and sign-off would occur. The system would be tested thoroughly, and sign-off would occur. Finally, often after 12-24 months, the system would be shipped to production. The entire system would then be passed off to a maintenance team.

During those 12-24 months, changes to the business for which the system was being built would have occurred. Thus, the day the system went live, it was already obsolete. Any changes required to bring the system up to date with the business would go through the same process above, again taking 12 months or more to see the light of day. Meanwhile, the business would have changed again.

The Customers for systems such as this repeatedly complained about the lack of responsiveness from the IT department. It simply took too long for a change to the system to be introduced into production, and therefore the system wasn't supporting the business.

The IT department, meanwhile, complained bitterly about their fickle Customers who always changed their mind. It seemed that they wanted everything, they wanted it yesterday, and wanted it for free (which is probably true). To make matters worse, the introduction of personal computers into organizations in the early 1980's combined with tools like spreadsheets and desktop database systems such as dBase gave end users the ability to build their own local systems to meet their local needs. However, these systems were disparate, standalone solutions that weren't scalable and didn't adhere to any corporate standards.

Why "Courage"?

The research upon which Boehm's Curve is predicated was performed during the 1970's. Since that time, factors such as the astronomical increase in computing power, the decentralization of computing with the arrival of the personal computer, the advent of object-oriented languages, and increasingly sophisticated development tools have conspired to flatten the Cost of Change curve substantially.

Consider, for example, what was required to compile a COBOL program 30 years ago when Boehm was compiling his research. The cards for the program would be submitted, and it would often take an hour or longer to determine if the program had even compiled, let alone if it would run. Compare that to modern IDE's with syntax highlighting and on-the-fly compilation. Most of these tools have a delay setting so that the tool won't attempt to compile the code too quickly while the user is typing!

So, the fear that a change to a system will incur tremendous costs is no longer valid. Changes do incur costs, but not at the exponential rate that Boehm described. Extreme Programming exploits this new found Courage to embrace changes as they occur, and thus deliver the system the Customer needed, not the one that was specified.

The traditional fear of change also often prevented the developers from making changes to a system that would improve its architecture, scalability, or maintainability. The practices of Test-Driven Development and Refactoring give the developers the courage to make these sorts of changes incrementally as they're required, all the while supported by a safety net of Unit Tests and Acceptance Tests.

The Customer, meanwhile, has the courage to request changes. New requirements may arrive as the result of a change in the business. Existing Stories may change as they are elaborated to the developers. The Customer is seeing the progress of the work through the Acceptance Tests and a working system at the end of each iteration.

For more information about Extreme Programming, visit our Resources page.