Better Software - April 2008 - (Page 27)

Iterative Development Iterative development is all about allocating time to improve the features requested, the user interface, and the performance characteristics. Iterative development also follows the Validation V. However, instead of releasing the system at the end of the V, we examine it from various angles, particularly the three listed above. Figure 5 shows the minor adjustment to figure 1 needed to obtain iterative development. Figures 6 through 8 depict iterative development. These figures show iteration (revision) happening within an increment. Other strategies are possible, but this is the most common. In constructing an iterative plan, two different strategies (and their blends) are possible. Each will work or backfire depending on the situation at hand. The art of iterative development is to guess well which strategy applies best at any given moment. The first strategy, shown in figures 6 through 8, is to develop everything as completely and correctly as possible the first time. The second strategy, illustrated in figures 9 through 11, is to develop as little as possible until things stabilize. The idea in the first strategy is: If we can get it mostly correct the first time, it will take the least amount of time to revise just the few parts needing correction, and then the whole thing can be released. Musicians use this strategy when laying down mixes, patching only the faulty bars. The idea in the second strategy is to expose early the places most likely to need rework, without having gone too far in the wrong direction. To illustrate the second strategy, let’s look at the art world, starting with Michelangelo’s painting of the Sistine Chapel [1]. Michelangelo knew that he would be perched on a scaffold each day, staring up at a small section of the vast ceiling, mixing his paints in wet plaster and trying to get a section complete before the plaster dried (his use of incremental development!). He knew that he would not have time to paint a section of (for example) a sun-lit body, climb down from the scaffold to see how his lighting angles Figure 5: The Validation V for iterative development. Figure 6: The first iteration delivers enough of feature 1 to evaluate what is correct and what needs revision. Figure 7: After the second iteration, some revised parts still need improvement. Figure 8: The third iteration produces the final and stable feature. www.StickyMinds.com APRIL 2008 BETTER SOFTWARE 27 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - April 2008

Better Software - April 2008 Contents Mark Your Calendar Contributions eLightenment Technology Speaking - A Change Would Do You Good Code Craft - A "D" In Programming, Part 1 Test Connection - Learning the Hardware Lessons Management Chronicles - The Art of Persuading Management Cover Story - Incremental and Iterative Development Developers...Start Your Engines Where Do I Go From Here Product Announcements 10 Things You Might Not Know About... The Last Word - Software Quality and the Prisoner's Dilemma Ad Index

Better Software - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.