0018-9162/05/$20.00 © 2005 IEEE34 ComputerCOVER FEATUREPP uu bb ll ii ss hh ee dd bb yy tt hh ee II EE EE EE CC oo mm pp uu tt ee rr SS oo cc ii ee tt yyIterative Rework: The Good, the Bad, and the UglyBecause the creative processes in developingand modifying software are subject tomyriad external and changeable forces, itis impossible to get all but the simplestproducts right in one pass. Long experi-ence has shown the advantages of iterative devel-opment, in which each iteration subsumes the pre-vious iteration’s software and adds capabilities tothe evolving product to produce a next version. Asdevelopers build and validate the next version’scapabilities, they rework the previous version toenhance its capabilities and fix defects discoveredwhile integrating the new and old versions.Iterative development can take many forms,depending on the project’s goals: Iterative proto-typing can help evolve a user interface. Agile devel-opment is a way to closely involve a prototypicalcustomer in a process that might repeat daily.Incremental build lets developers produce weeklybuilds of an evolving product. A spiral model canhelp the team confront and mitigate risk in an evolv-ing product.Each iteration involves a certain amount ofrework to enhance and fix existing capabilities (thegood). However, excessive rework could indicateproblems in the requirements, the developers’ skillsand motivation, the development processes or tech-nology used, or all of the above (the bad). Exorbitantlevels of rework result in truly untenable situations(the ugly).On the other hand, too little rework could indi-cate insufficient review and testing or too littleanticipation of the product features needed to sup-port the next version (bad that can turn ugly).Understanding and correcting the root causes ofproblems that result from too much or too littlerework can significantly increase productivity,quality, developer morale, and customer satisfac-tion.ITERATIVE DEVELOPMENT MODELSAll forms of iterative development provide a wayto•continuously integrate and validate the evolvingproduct, • frequently demonstrate progress, • alert developers early on about problems,• deliver subset capabilities early on, and• systematically incorporate the inevitable reworkthat occurs in software development. Agile and incremental-build are two commonlyused iterative development models. In both mod-els, significant changes to requirements, design con-straints, or environmental factors such as changesto middleware application programming interfaces(APIs) or hardware features can require significantrework of the design and existing code.Agile developmentAlthough the agile theme has several variations,most agile process models adhere to five principles(http://agilemanifesto.org/principles.html):• Continuously involve a prototypical customer.In software development, some rework is both inevitable and beneficial.But how much is too much and how little is too little? Understanding thenature of rework and why it occurs can help answer these questions.Richard E.FairleyOregon Health andScience UniversityMary JaneWillshireColorado TechnicalUniversity• Develop test cases and test scenarios beforeimplementing the next version.• Implement and test the next version.• Demonstrate each version to the customer andelicit the next requirements.• Periodically deliver evolving subsets of theproduct into the operational environment. The customer’s role is to review progress and pro-vide the story line that determines the requirementsfor new capabilities and revisions to demonstratedcapabilities (www.martinfowler.com/articles/newMethodology.html).Figure 1 depicts an iterative model for agile devel-opment. Some agile process models require devel-opers to produce a next version of a running systemwithin one workday. Some use pair programming,in which pairs of developers share a computer terminal to develop their software. Experience with agile models indicates that theresulting products rate high in customer satisfac-tion and have low defect levels. Customer satisfac-tion, however, depends critically on involving aknowledgeable prototypical customer. Some crit-ics maintain that products from an agile processmay have functional structures, which are hard tomodify, and no design documentation. Others notethe approach’s lack of scalability.Incremental buildIn contrast to agile models, in which require-ments and architecture evolve, the incremental-build model is based on stable requirements and anarchitectural design. As Figure 2a shows, the modelpartitions requirements and architecture into a pri-oritized sequence of builds. Each build adds capa-bilities to the incrementally growing product.Developers typically produce a next version of ademonstrable system each week. Each version inte-grates, tests, and demonstrates the progress that alldevelopers have made.The incremental-build process works well wheneach team consists of two to six developers plus ateam leader. Team members can work as individu-als or perhaps in pairs using an agile process. Eachindividual or pair will typically produce severalunofficial builds during each development cycleusing a copy of the current official version as a test-bed.The incremental-build model scales well to largeprojects. Developers partition the architecture intowell-defined subsystems and allocate requirementsand interfaces to each. The team can independentlytest and demonstrate subsystems, perhaps usingSeptember 2005 35HearcustomerstorySpecifyrequirement(s)Write test scenario(s)Add new features; review, test, andreworkDemonstratecapabilitiesCustomerStarthereDeliverhereFigure 1. Steps in the agile development process. The process from customerstory to demonstrated capabilities is iterative in nature, with Iterations typicallyoccurring in cycles of one day or less. Developers may periodically deliverversions to users.Buildfeature set N• • •• • • • • •Buildfeature set 2Buildfeature set 1Time Validatefeature set 1Validatefeature sets 1+2Validate• • • • • •IncrementalreworkDemonstratefeature set 1DemonstrateFS 1 + FS 2Demo. . . . .Demo and deliverFS1 … FSNValidateFS1 … FSNDesignpartitioningIncrementalvalidation Incremental validation Incremental validation (a)(b)Requirements specification DesignpartitioningArchitecturaldesignIncrementalvalidationand reworkIncrementalverificationand reworkIncrementalbuildsCustomer Figure 2. An