Designing The Value of Time

{\rtf1\ansi\ansicpg1252\deff0\deflang16393{\fonttbl{\f0\froman\fcharset0 Times New Roman;}{\f1\fnil\fcharset0 Calibri;}{\f2\fnil\fcharset2 Symbol;}}
{\colortbl ;\red0\green0\blue255;}
{\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\sb100\sa100\f0\fs24 Incremental design is a way to deliver functionality early and continue delivering functionality weekly for the life of the project. XP pushes incrementalism of design to its limit, suggesting that projects run more smoothly if design is part of daily business. This chapter explores the technical, economic, and human reasons for embracing incremental design.\par
Permaculture is a philosophy and practice of sustainable living in a balanced ecosystem. As in Permaculture, I think of design as a system of beneficially related elements. Each word in this definition is loaded with meaning. "Elements" suggests that systems can't be comprehended only as wholes. "Related" suggests that the elements in a design don't stand alone but rather come together in relation to each other. These relationships, along with the decomposition of a design into elements, are what the designer manipulates, consciously or unconsciously, for good or ill. "Beneficially" suggests that the relationships can strengthen the elements, making each more powerful than it would be alone and making the system something more than what would be suggested by examining the elements in isolation.\par
Design is what makes software so valuable. Unlike the physical world, in software we can endlessly replicate our elements at no cost. When we create new, more beneficial relationships between elements, we can spread these relationships to all existing elements. Software is a leverage game. One good idea can save millions of dollars in costs and create many millions of dollars in revenue.\par
Unfortunately, design in software has been shackled by metaphors from physical design activities. When you have a skyscraper fifty stories high, you can't decide to take it up another fifty stories because you've already rented all the space. There is no way to jack up a huge building and replace the foundation with something stronger.\par
The equivalent transformation is daily business in software. A distributed system might use remote procedure calls as its initial communication technology. As experience with the system grows, the team can see how to improve the system by moving to CORBA. A year later the team replaces CORBA with a message queue. At every stage of this process the system is running. Every stage of the process provides the experience to get to the next stage. It is as if we started with a dog house and, by gradually replacing pieces, ended up with a skyscraper, all the while continuously occupying the structure. This is absurd in the physical world but it's a sensible, low-risk way to develop software.\par
In the physical world the individual transformations cost too much for incremental design to work well. The intermediate stages have too little value or the changes are too costly (pieces get destroyed and are expensive to duplicate in the rebuilding process). Still, as How Buildings Learn by Stewart Brand documents, even physical structures undergo incremental design and construction, with the experience of the existing structure informing the next stage of design in ways that speculation cannot.\par
Part of what makes incremental design valuable in software is that we are often writing applications for the first time. Even if this is the umpteenth variation on a theme, there is always a better way to design the software. Because design has leverage and because design ideas improve with experience, patience is one of the most valuable skills a software designer can possess. There is an art to designing just enough to get feedback, and then using that feedback to improve the design enough to get the next round of feedback.\par
One common metaphor for software is building construction. For example, Steve McConnell in Code Complete pushes the software construction metaphor. Beth Andres-Beck, Smith College theater student, has pointed out the fundamental flaw in the metaphor: it is extremely difficult to reverse progress in the construction world. One day you can make changes to the floor plan by moving around pegs and string for free. Two days later, after the foundation has been poured, the same change costs you $10,000. This asymmetry of costs shapes the activities and their relationships in construction.\par
In software, however, reversing a day's work is trivial. All you ever lose is that day's work. Given this radical difference, the sequence of activities appropriate in construction are not appropriate for software. The question is not whether to design, but when to design.\par
McConnell writes, "In ten years the pendulum has swung from 'design everything' to 'design nothing.' But the alternative to BDUF [Big Design Up Front] isn't no design up front, it's a Little Design Up Front (LDUF) or Enough Design Up Front (ENUF)." This is a strawman argument. The alternative to designing before implementing is designing after implementing. Some design up-front is necessary, but just enough to get the initial implementation. Further design takes place once the implementation is in place and the real constraints on the design are obvious. Far from "design nothing," the XP strategy is "design always."\par
The following graphs help you visualize for yourself when you should design. The vertical axis of the graph is the quality of the design. There is a horizontal line for the minimum quality of the design necessary for success. Software design is curious in that there are usually many designs that are good enough for the software to be successful. Design quality doesn't ensure success, but design failure can ensure failure.\par
Each graph will have three points, one for how you would design "by instinct", one for how you would design if you thought about the design really hard, and one for how you would design in the light of experience. The relationship of the three points and the location of the minimal design threshold will suggest whether designing up front is even an option for you, or whether you would be better off with incremental design.\par
\pard\sb100\sa100\qc Another factor in deciding when to design is the cost. If you design early, the initial cost of the design is simply the time you spend. Overall costs may be high if you make many mistakes that have to be repaired or worked around for the life of the project. The cost of designing based on experience is the time for the bare-bones initial design, which is lower than that of designing up front, plus the cost of retrofitting later design decisions into running code and live data. Many XP practices are intended to lower the cost of ongoing design.\par
\pard\sb100\sa100 A particularly important design problem is the design of databases. Pramod Sadalage of ThoughtWorks came up with an elegant incremental database design strategy:\par
\pard{\pntext\f2\'B7\tab}{\*\pn\pnlvlblt\pnf2\pnindent360{\pntxtb\'B7}}\fi-360\li720\sb100\sa100 Start with an empty database.\par
{\pntext\f2\'B7\tab}Add all tables and columns with automated scripts that also migrate any existing data as necessary.\par
{\pntext\f2\'B7\tab}Sequentially number the scripts so a database at any earlier stage can be brought up to any later stage by running the scripts.\par
\pard\sb100\sa100 A particular version of the code expects a particular version of the database design. Deploying a new version of the system involves rolling out the new code and running any design/migration scripts. To reduce downtime, deployments should be kept small and frequent.\par
The most powerful design heuristic I know is Once and Only Once: data, structure, or logic should exist in only one place in the system. I discover the need for design investment by spotting duplication. I work with the design until I can find a way to unify the separate expressions. Patterns are the common targets of these design improvements, structures of code that generally do not require duplication. Duplication is bad because it implies that to make one conceptual change you have to change code in several places. Code without duplication has the property that one conceptual change requires one change of code. If your code has this property, continuing changes remain inexpensive.\par
The arguments against incremental design come down to "we can't" and "we won't." "Can't" is addressable by learning the skills necessary to design in the context of running code and data. "Won't" is a bit tougher. I've certainly worked on systems when I knew about many potential design improvements but I never invested the time to realize them in the system. Most often, I didn't improve the design because I was focused too narrowly on the problem of adding one more feature to the system. I didn't try to balance the whole team's productivity with today's task. I didn't think about how bad I felt jamming one more feature in where it didn't belong. I didn't think about how much motivation and satisfaction there is in doing a really good job.\par
If you are confronted with a big ball of mud, you can still begin improving the design. Begin lighting the lamps where you walk. As you modify code, clean up a little. Resist the temptation to take your design improvements too far afield. Make a habit of improving the design that affects you today. Make a public list of bigger improvements that need to be tackled over time. Soon you'll find that the code you change all the time is pretty well designed. It'll be a surprise when you run into an untouched part of the system that is designed the old way.\par
Sometimes the team can't make a design improvement in a week and still deliver new functionality. Part of incremental design is figuring out how to stage design improvements. Take the example that led off this chapter, moving from remote procedure calls to CORBA. Even with careful design originally, some assumptions that you are using remote procedure calls will leak out into code that is unrelated to communication. As you touch the existing code, concentrate those assumptions in as few places as possible. Eventually, the job of putting in the new communication protocol will fit into a week.\par
Such long-running changes may seem to cost more than stopping development and making the change all at once. Designing software is not done for its own sake in XP. Design is in service of a trust relationship between technical and business people. Weekly delivery of requested functionality is the cornerstone of that relationship. It doesn't matter what the theoretical best way to design might be. The convenience of the designers is lower on the priority list than maintaining the diverse relationships that create value within the team.\par
In summary, the shift to XP-style design is a shift in the timing of design decisions. Design is deferred until it can be made in the light of experience and the decisions can be used immediately. This allows the team to:\par
\pard{\pntext\f2\'B7\tab}{\*\pn\pnlvlblt\pnf2\pnindent360{\pntxtb\'B7}}\fi-360\li720\sb100\sa100 Deploy software sooner.\par
{\pntext\f2\'B7\tab}Make decisions with certainty.\par
{\pntext\f2\'B7\tab}Avoid living with bad decisions.\par
{\pntext\f2\'B7\tab}Maintain the pace of development as the original design assumptions are superseded.\par
\pard\sb100\sa100 The price of this strategy is that it requires the discipline to continue investing in design throughout the life of the project and to make large changes in small steps, so as to maintain the flow of valuable new functionality.\par
{\field{\*\fldinst{HYPERLINK "1991535.html"HYPERLINK "1991535.html"}}{\fldrslt{}}}\f0\fs24\par
\pard\sa200\sl276\slmult1\lang9\f1\fs22\par
}