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