Emergent Architecture vs. Early Prototyping
Emergent design (also referred to as emergent architecture ) is an evolutionary prototyping technique used in XP to evolve a design through refactoring from code, with little or no significant up-front design.
Conversely, early prototyping is a technique that involves creating lots of small, transitory programs and program fragments as an integral part of the up-front design process.
These two approaches are almost diametrically opposed in the philosophy that drives them, and yet in some ways they re grounded in the same set of goals.
Early prototyping traditionally fits into supposedly less agile methodologies-that take a design-up-front approach. However, it also provides many of the benefits of the agile approach (e.g., early feedback), while retaining the more rigorous benefits gained from designing a system before coding it. The key benefit of early prototyping is that it provides a mechanism that helps to get the architecture and design right very early in the project.
Contrast this with the XP approach of emergent architecture. The theory here is that it should be possible to launch straight into the project without spending time up front (before production coding begins) thinking the architecture through. Done the XP way, the architecture itself would (in theory, at least) arise spontaneously as the codebase evolves.
In a discussion on Usenet regarding emergent architecture, XP author Robert C. Martin wrote the following:
| Light Bulb | The fact that the architecture arises spontaneously does not mean that the architecture doesn t take work to derive. It does! Lots of work. It s just that the developers have more and more information with each new iteration. Each new batch of information solves more of the architecture puzzle. I agree, architecture requires up-front planning. However, I don t define ˜up-front as meaning ˜pre-code . I think you have to write some code up front to find the real architecture. [12] |
I almost choked on my cup of tea when I read the brilliantly circular I don t define ˜up-front as meaning ˜pre-code . We agree with the kids , smoking cigarettes isn t at all bad for you, but then we don t define smoking as meaning inhaling cigarette smoke.
This reply to Martin s message was posted by David Van Camp:
Sorry, I simply don t buy it. I ve been though this ˜evolution too many times. I call it ˜redesign . It is painful and labor intensive . To call it ˜refactoring is not to give it justice . [13]
These two messages highlight the differences between the two approaches. In XP, emergent architecture is achieved via evolutionary prototyping. With this approach, the prototype itself becomes the production code.
Conversely, with traditional early prototyping, the prototype is largely abandoned . It s kept for reference, but the production version is begun afresh. No time is wasted trying to refactor the prototype code into something more acceptable: Its place is simply to explore, to find out what s possible, and to get some idea of what s going to be involved in the real thing. That isn t to say that some code won t be cut and pasted from the prototype. However, the main thing that s kept is the knowledge and insight into the solution that the prototype gives us.
Combined with up-front design, we feel that this is a much more realistic approach to getting the architecture right than its evolutionary cousin.
 |
Early prototyping is discussed in more detail in the online article titled Emergent Design vs. Early Prototyping. [14]
| |
| |
| FANGS | Emergent design relies on many XP practices/values being followed to the letter ”in particular, pair programming, unit tests, collective ownership, coding standards, and simplicity. If anyone on the team starts to slip, code quality could immediately start to suffer (e.g., making changes to the design without full unit test coverage could result in undiscovered bugs slipping through). |
Emergent design ignores the benefits of up-front design, instead using the erroneous assumption that you can t get the design right early as a reason not to do up-front design at all (or at least to reduce it to a 10-minute design workshop).
| |
| |
| SOLUTIONS | XP is very much opposed to adding extra layers of code just in case we need it later. We re 100% in agreement on this. We do, however, make the distinction between that and adding in code because we ve designed for it and because we know that it s going to be an essential part of the system. A documented up-front design provides a roadmap, with customer requirements broken down into engineering tasks. These tasks are estimable and schedulable, and so can be prioritized across iterations. Taking this approach lets the team make an intelligent decision regarding what to implement now based on how much of it would need to be rewritten later. One of the most-feared problems with BDUF ”that the customer doesn t get to see visible signs of progress for a long time ”can be reduced in a couple of ways:
A truly powerful approach would be to combine effective up-front design modeling techniques with XP s unit testing and refactoring techniques. The trick is to get the balance right: to spend sufficient time on architecture and design up front (precode) so that the design doesn t churn and spin out countless refactoring eddies (which create an illusion of progress when the project is really stuck in neutral). |
| |
| |
More about this combined approach in Chapter 15.
| |
[12] Robert C. Martin posting to the newsgroup comp.software.extreme-programming, subject: XP and Rational Unified Process, August 19, 2002.
[13] David Van Camp posting to the newsgroup comp.software.extreme-programming, subject: XP and Rational Unified Process, August 20, 2002.
[14] Matt Stephens, Emergent Design vs. Early Prototyping, http://www.softwarereality.com/design/early_prototyping.jsp, May 26, 2003.
EAN: 2147483647
Pages: 156