With slippery requirements, not to mention slippery runways, sometimes you have to do everything at once: programming begins and contributes to requirements and test development. Iterative development becomes a heuristic for discovering further needs. This article lays out some basics of Extreme programming from the perspective of an airline pilot turned developer.
In so many of the development projects I've been on, the requirements were difficult to pinpoint at the outset. The business side knew generally what they wanted, but the specifics-things that could affect the fundamental design-could not be anticipated. Datamart and data warehousing applications have been particularly sensitive to this inability to fully lay out the particulars of reports that will come in the future. Web applications woven into complex business agreements are equally pliable. In programming these projects, I've often drawn on lessons I learned flying for a commuter airline on those stormy days where most people would rather be at work than traveling.
In the world of air flight, a flight plan rigidly defines the checkpoints, route, time, and fuel required to get from point A to point B. Using atmospheric data plugged into aircraft performance equations, accurate predictive estimates of navigation are obtained. Once in flight, the actual progress is compared to the plan. In a world of pure physics, the flight plan estimates of fuel and time exactly equal the actual flight. When the weather conditions are unpleasant-such as fog, thunderstorms, or frozen precipitation-the actual flight events deviate from the plan.
Take a typical summer flight from New York to Washington, D.C., with thunderstorms along the route. Thunderstorms, obstacles that are inflexible and too big to go around, often pop up with short notice and mushroom in size. Ever heard of that description on your projects? Before departure, a flight plan is prepared defining the route with fuel and time estimates. The pilots review the real-time weather radar and weather reports to get a general impression of storm movement and intensity, developing a practical avoidance strategy. Due to the constraints of airspace usage, combined with the dynamics of thunderstorm development and movement, the strategy is not expressed as a full plan but rather an overview of prospective options.
The flight crew departs with the big picture of the weather. In flight, they use their aircraft weather radar for ongoing real-time pictures of the storms. The aircraft weather radar provides the most practical data for the flight, because it provides the only picture that matters: the position of the storms relative to the aircraft. The flight crew interprets their airborne weather radar display in a continuous feedback loop to reach conclusions about the safest route. The flight crew deviates from the flight plan and forges a new route based on conditions that are, by their nature, impossible to predict. The flight plan still serves the key purpose as a baseline for comparing the anticipated to the actual, to verify that the progress being made is acceptable for the amount of fuel on board.
In the world of software, there are those projects where the weather causes low visibility. The overall flight plan is just as important, but the exact route to be followed cannot be defined due to changing conditions. In these cases, the exact route can only be determined by getting started and reacting to conditions through observation and measurement. In fact, certain conditions cannot be known until you are under way. If you delay in an effort to acquire requirements that are so absolute that the path is completely defined, you will never depart.
Extreme Programming, also known as Agile Development, tries to get the flight off the ground and get the software project to its destination successfully. The "Extreme" approach is to take off, keeping your options open, then making adjustments along the way.
I once worked on a Web-based intranet datamart for a large homecare provider. We had to collect lots of data