This post originated from an RSS feed registered with .NET Buzz
by Darrell Norton.
Original Post: Extreme Programming Explained: 2nd ed - Part 4
Feed Title: Darrell Norton's Blog
Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx
Feed Description: Agile Software Development: Scrum, XP, et al with .NET
Last time we looked at the various members of the XP team. Now let's take a look at one of XP's hardest disciplines, that of simple design. Here is the criteria for simple designs (from chapter 14):
Appropriate for the intended audience. It doesn't matter how brilliant and elegant a piece of design is; if the people who need to work with it don't understand it, it isn't simple for them.
Communicative. Every idea that needs to be communicated is represented in the system. Like words in a vocabulary, the elements of the system communicate to future readers.
Factored. Duplication of logic or structure makes code hard to understand and modify.
Minimal. Within the above three constraints, the system should have the fewest elements possible. Fewer elements means less to test, document, and communicate.
In XP, programmers always try to write the simplest code that could possibly work. This does not mean that there is no design, it's just not done all up-front. This is where the construction metaphor, that software development is like building a bridge or a skyscraper, is harmful and limiting to our profession. Software is just that, soft. Keeping the design simple postpones the decision on how to design something until the last responsible moment. This gives the design as much time to learn from experience and evolving requirements as possible without unduly damaging the design by waiting too long to implement it (waiting too long would be past the last responsible moment). Keeping the design simple also enables XP teams to move faster since they have less baggage to lug around (code to maintain).
You can argue that both construction and software development can postpone decisions until the last responsible moment. That is true, however, in programming the code is the design and the last responsible moment can occur much later in the process than in construction. Take a house for example. You can make changes to the architectural blueprints all you want for free, but after the foundation of your house is poured if you want to add 10 feet extra to the back of the room, that's going to cost you a lot. In software, if the design has been developed properly with time-proven OO techniques, adding an extension to the system can as simple as adding a class.
The most important point to remember is that just like agile methodologies are planning-driven not plan-driven, XP is designing-driven not design-driven.
Previous Topic
