{"id":5003328,"date":"2015-12-16T23:49:09","date_gmt":"2015-12-17T07:49:09","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003328"},"modified":"2022-08-30T11:45:27","modified_gmt":"2022-08-30T18:45:27","slug":"simple-design","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/simple-design\/","title":{"rendered":"Simple Design"},"content":{"rendered":"<p>A team adopting the \u201csimple design\u201d practice bases its software design strategy on the following principles:<\/p>\n<ul>\n<li>design is an ongoing activity, which includes\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/refactoring\/\">refactoring<\/a>\u00a0and heuristics such as YAGNI<\/li>\n<li>design quality is evaluated based on the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/rules-of-simplicity\/\">rules of code simplicity<\/a><\/li>\n<li>all design elements such as\u00a0<a href=\"https:\/\/en.wikipedia.org\/wiki\/Design_pattern\">\u201cdesign patterns\u201d<\/a>, plugin-based architectures, etc. are seen as having costs as well as benefits, and design costs must be justified;<\/li>\n<li>design decisions should be deferred until the \u201clast responsible moment\u201d, so as to collect as much information as possible on the benefits of the chosen option before incurring its costs.<\/li>\n<\/ul>\n<h2>Also Known As<\/h2>\n<ul>\n<li>the practice is often reduced to the acronym YAGNI, for \u201cYou Aren\u2019t Gonna Need It\u201d; this alludes to the usual counter-argument when a programmer tries to propose a costly design element based on its future benefits only (\u201cWe\u2019re going to need this Factory sooner or later, we might as well put it in now.\u201d \u201cNo, you aren\u2019t gonna need it.\u201d)<\/li>\n<li>another common term is \u201cemergent design\u201d, emphasizing that good global design can result from consistently paying attention to the local qualities of code structure (by analogy with the processes studied by complexity theorists where purely local rules reliably give rise to consistent global properties)<\/li>\n<\/ul>\n<h2>Common Pitfalls<\/h2>\n<ul>\n<li>the first (and fatal) mistake would be to downplay, for instance, while staffing a team, the importance of significant design skill among the team, on the basis that \u201cthe design will emerge\u201d; emergence is not magic and such skills are still crucial<\/li>\n<li>\u201csimple design\u201d only refers to the \u201csoftware\u201d design; it is misleading to invoke the simple design practice to justify decisions that have to do with a customer or <a href=\"https:\/\/agilealliance.org\/glossary\/product-owner\/\">product owner\u2019s<\/a>\u00a0requirements, or usability considerations<\/li>\n<li>the practice may be ill-advised when design practices are unlikely to be consistent, for instance, if the development group is large and geographically distributed<\/li>\n<\/ul>\n<h2>Signs Of Use<\/h2>\n<ul>\n<li>the team maintains a \u201cbacklog\u201d of design-specific tasks:\n<ul>\n<li>design flaws requiring explicit remediation through refactoring<\/li>\n<li>opportunities to simplify existing code<\/li>\n<li>potential design decisions are deferred until more information comes in<\/li>\n<\/ul>\n<\/li>\n<li>this backlog doesn\u2019t remain stagnant, or a mere list of complaints never addressed; the team sets aside enough of its productive time to regularly address the issues (or decide to live with them)<\/li>\n<li>the team regularly uses one or more of the ancillary practices which offer explicit opportunities to discuss design<\/li>\n<li>any impression that relatively straightforward functional changes require inordinate amounts of effort to implement is a \u201cwarning sign\u201d that the practice may not be effectively used<\/li>\n<\/ul>\n<h2>Expected Benefits<\/h2>\n<ul>\n<li>mitigates the common risk of overdesign (\u201cgold plating\u201d)<\/li>\n<li>has been claimed to \u201cflatten the cost of change curve\u201d \u2013 i.e. to keep the software easy to change, because all design decisions are agnostic to which particular changes are expected<\/li>\n<\/ul>\n<h2>Origins<\/h2>\n<p>The phrase YAGNI is associated with\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">Extreme Programming<\/a>\u00a0from its earliest days.<\/p>\n<h2>Skill Levels<\/h2>\n<p>As an individual contributor:<\/p>\n<ul>\n<li>Beginner: able to identify design elements that do not \u201cpull their weight\u201d (aren\u2019t beneficial enough to justify their complexity) and refactor to simplify the code structure<\/li>\n<li>Intermediate: able to defer a design decision that may be required by a future requirement, and to identify the conditions under which the decision should be arbitrated<\/li>\n<li>Advanced: able to identify the right moment to introduce a far-reaching design decision, such as a plugins-based architecture in a desktop application<\/li>\n<\/ul>\n<p>On the team level, the litmus test is whether the team is able to \u201cshare\u201d design decisions, so that these are not based on individual decrees by the architect or lead programmer, but understood and carried out by all developers on the team.<\/p>\n<h2>Further Reading<\/h2>\n<ul>\n<li><a href=\"http:\/\/www.martinfowler.com\/articles\/designDead.html\">Is Design Dead?<\/a>, by Martin Fowler, remains one of the most perceptive discussions of how Agile teams approach design<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>A team adopting the &#8220;simple design&#8221; practice bases its software design strategy on a set of &#8220;simple design&#8221; principles.<\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[],"class_list":["post-5003328","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003328","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003328"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003328\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003328"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003328"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003328"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}