<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-0rSxLFlmQfyKrgnqi1NKrg"
    name="simple_design,1.6109092258980447E-306" guid="-0rSxLFlmQfyKrgnqi1NKrg" changeDate="2006-11-08T19:39:05.846-0500"
    version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_xp__simple_design&quot; name=&quot;XE_xp__simple_design&quot;>&lt;/a>&lt;a id=&quot;XE_simple_design__practice_of&quot; name=&quot;XE_simple_design__practice_of&quot;>&lt;/a>&lt;a id=&quot;XE_engineering_practices__simple_design&quot; name=&quot;XE_engineering_practices__simple_design&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    Description&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The design strategy in XP is to create the simplest design that meets your current requirements, as reflected in the&#xD;
    current test cases. In many domains, &quot;simplest design&quot; is ambiguous, but it is a well-defined term in XP. A simple&#xD;
    design has these four characteristics, listed in priority order:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The system runs all the tests.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It contains no duplicate code.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The code states the programmers's intent very clearly.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It contains the fewest possible number of classes and methods.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Design in Extreme Programming is much more incremental than in any other methodology. The practice of Test-Driven&#xD;
    Development describes how the system is created in many small steps, driven by tests that programmers write. Each of&#xD;
    these tests is a probe into the design of the system, allowing the developers to explore the system as it is being&#xD;
    created. This is quite a contrast to other methodologies where design is a separate phase of either the project or the&#xD;
    iteration. In XP, design quite literally happens all the time.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It takes a tremendous amount of courage to stop designing and start coding. Almost all developers are taught that they&#xD;
    should understand everything about the system before committing that knowledge to code. The reason, they've always been&#xD;
    told, is that code is hard to change. Once it is laid on its virtual paper, changing it involves understanding the&#xD;
    hidden assumptions of the original developer, unseen couplings, months-long validation and verification procedures,&#xD;
    etc. But if code could be changed with impunity, developers could afford to defer design decisions until later,&#xD;
    understand the system incrementally, and implement in pieces.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The strategy of building software in this manner is based on the following reasoning:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Given that all requirements aren't known on the first day of the project, the development style must be adjusted to&#xD;
        accommodate new understanding from customers and changes in the business climate.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If a design decision does not have to be made now, avoid guessing by deferring the decision until it is needed. By&#xD;
        that time, there is a better chance that enough understanding will exist to support a better decision.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change happens during the lifetime of a project. Decisions made once will be changed. The software must be designed&#xD;
        and implemented in such a way that changes can be accommodated easily.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Designs seldom survive their first skirmish with code. The act of coding provides feedback to the developer about&#xD;
        the system. This learning must be reflected in the design. If the design is already cast before coding begins, this&#xD;
        feedback is more difficult and costly to put back into the design.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Here are some guidelines to help in arriving at a simple design:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Look for a simple way to solve a problem. Software is hard, so there will be plenty of time for complexity later.&#xD;
        For now, keep it simple. Simple, however, does not mean stupid. Pay attention to good design principles when&#xD;
        forming a system incrementally.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resist the temptation to add infrastructure or other features that might be needed later. Chances are they won't be&#xD;
        (YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep&#xD;
        implementation simple. Let the second user pay for the generality.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Seek out and destroy duplication. The practice of &lt;a class=&quot;elementLink&quot; href=&quot;./../../../xp/guidances/concepts/refactoring_xp_programming.html&quot; guid=&quot;1.4410217108363206E-306&quot;>Refactoring&lt;/a> is the most powerful tool in the arsenal. It is through removing&#xD;
        duplication that new classes, methods, and larger scale systems are born.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated&#xD;
        again in less time and better than the first time by leveraging what was learned the first time.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Benefits&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Small initial investment&lt;/b>: There is no need to invest in frameworks or generality that might be or might not&#xD;
        be required in the future.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Maintainability&lt;/b>: Simple design will keep the design from rotting and dying prematurely. The more complex the&#xD;
        design is, the harder it is to understand and preserve and the more rapidly it will decay.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Flexibility&lt;/b>: Simple systems are always easier to change than more complex systems.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Agility&lt;/b>: Simple systems are faster to change than more complex systems.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>