- The Fundamental Argument
- Process: How We Got Here
- The Next Step: Velocity
- Approaching Tomorrow
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Process: How We Got Here
The software landscape has gone through three major "shifts" in thinking: code and fix, the waterfall, and Agile development. Each way of thinking about the software process addresses the concerns of a particular era.
Code and Fix
The first software projects would be considered trivial today. Calculating the distance an artillery piece will land from its target is now more likely a physics problem for a high school senior than a job for a top-notch Department of Defense scientist. The very first programs were so simple that the staff engineer could write the code, execute a few dozen tests, and be confident in the correctness of the program. This early style of coding has earned the title "code and fix."
After World War II, computers stepped up to solve more complex problems. Non-technical customers begin to enter the equation, each individual asking for software he couldn’t describe, but would know when he saw it. User interfaces and options made the number of possibilities infinite. Schedules became harder to predict, and overruns became the norm. Testing and fixing costs skyrocketed; communication and integration between teams threatened to bring large-scale development to a halt. In the mid-1970s, IBM undertook the creation of OS/360, a multitasking, multi-person operating system with a staff of more than 250 people at its peak. By that point, it was clear that "code and fix" was no longer viable.
The Waterfall Method
The next great development idea was the waterfall model, popularized by Winston Royce (see sidebar). The waterfall model breaks development into phases, such as requirements, design, code, test, and deploy. The model requires formal "gates" for each phase: requirements review, design review, and so on. These formal processes are supposed to ensure correctness early and guarantee that all changes have been approved. Thus, the schedule is predictable, defects are removed early, and the company can hire specialists who will be expert at each phase.
The waterfall model also has its share of weaknesses, however, including difficulty in responding to change. If the customer cannot articulate his need until he’s had some hands-on time with the system, then it has to be developed before the requirements are complete and correct. In that kind of world, the "plan your work, work your plan" approach can result in software that is on time and on budget...it just doesn’t happen to do what the customer needs it to do.
In other words, Royce was recommending Agile development principles 30 years ago.
Agile Development: The Pendulum Swings
An extreme version of the waterfall model requires checklists and signoff for each phase; the project cannot move forward until the proper paperwork is done for each phase. Designed to catch errors early, these heavyweight standards often have the unintended consequence of slowing development. The Agile software movement is a reaction to those heavyweight process descriptions. Two principles are key to that manifesto:
- Value working software. This rule implies dropping everything that isn’t adding value. If status meetings, reports, design documents, and review meetings aren’t adding value, stop doing them. Instead, do the simplest thing that can possibly work, and concentrate on delivering working software—the most valuable work product of a software team.
- Value individuals. Focusing on individuals and interactions implies that having a practitioner working in the field is better than having a static plan. This approach often means heavy feedback with the customer and adjusting the plan to meet reality. Combining those practices with valuing working software means that the customer gets something he can use earlier, and, should he have to cut features, he can cut those of least value.
Agile development takes discipline, and it’s possible to get it wrong. A litany of support activities exists to enable Agile development, such as test-driven development and pair programming. Specific information about these practices is available at XProgramming.com.