Delivering Software

Ward Cunningham

Position Paper
XP Beyond Limitations
XP/Agile Universe 2002
 

Extreme Programming consists of a set of practices that are surprisingly complete in a wide variety of situations. Are there limits to the applicable situations? Sure. But every limitation I have found to date can be traced to disagreement with a fundamental assumption of extreme programming:

    Assumption: The purpose of our activity is to deliver software.

The two key words here are 'deliver' and 'software'. Let's consider both in turn. Extreme programming practices rely on self-organization that is possible when individuals' compelling interests are aligned. Delivery provides that alignment for extreme programming. Should delivery be infrequent or remote then other compelling interests, such as 'appearing important', dominate the organization. A manager's compelling interest may be to run a 100 person organization, perhaps because there are jobs within the company that cannot be done without 100 people, and the manager wants the experience to do those jobs. It may be in the companies best interest to provide that manager with 100 developers so that he gains this experience even if that is not the shortest path to delivery.

Large organizations always have multiple goals which may or may not be harmonized. When goals are in harmony then individual effort toward any goal is at least indirectly contributing to the primary goal of the organization which for commercial organizations is often increasing shareholder value. Whenever delivering software is one of the harmonized goals for an organization then there is a place in that organization for extreme programming.

The second of our two key words is 'software'. Extreme programming relies on emergent abstraction achieved though continual factoring of the software. Software has more in common with folk tunes than circuit boards in this regard in that both software and folk tunes are improved through rework while a circuit board becomes brittle and breaks. It is a mistake to manage the design of software as one would manage the design of circuit boards as the software then becomes brittle too which is a loss.

Hardware design actually aspires to be more like software and is progressing in this direction through programmable components. The essential measure here is change turn-around time for which 30 seconds is considered good and is easily achieved through in-place programming. Unfortunately the true cost of change can still escalate with program complexity unless means for effective rework are in place. This comes down to effective factoring of resource allocations such as registers, timers, counters, ports, bits and so forth. The goal isn't so much to get above these things as to be able to talk about them effectively. I've had some initial success using objects to model the 'organization' of microcontroller code rather than modeling the 'computation' it is to perform.

So in both the case of the large company and the small processor it is emergent organization that is the key to value and original use of flexible models that enables the extreme programming practices to apply.