Additional clarity on ball of mud.

architecture.html

@@ -31,7 +31,7 @@
 		
 		<p>This is where <b>architecture</b> comes in. Architecture is a way of organizing code, just like building architecture is a way of organizing space. The idea of software architecture has at its foundation a principle of <b>information hiding</b>: the less a part of a program knows about other parts of a program, the easier it is to change. The most popular information hiding strategy is <b>encapsulation</b>: this is the idea of designing self-contained abstractions with well-defined interfaces that separate different concerns in a program. Programming languages offer encapsulation support through things like <b>functions</b> and <b>classes</b>, which encapsulate data and functionality together. Another programming language encapsulation method is <b>scoping</b>, which hides variables and other names from other parts of program outside a scope. All of these strategies attempt to encourage developers to maximize information hiding and separation of concerns. If you get your encapsulation right, you should be able to easily make changes to a program's behavior without having to change <em>everything</em> about it's implementation.</p>
 		
-		<p>When encapsulation strategies fail, one can end up with what some affectionately call a "ball of mud" architecture or "spaghetti code". A more precise concept is <b>cross-cutting concerns</b>, which are things like features and functionality that span multiple different components of a system, or even an entire system. There is some evidence that cross-cutting concerns can lead to difficulties in program comprehension and long-term design degradation (<a href="#walker">Walker et al. 2012</a>), all of which reduce productivity and increase the risk of defects. As long-lived systems get harder to change, they can take on <em>technical debt</em>, which is the degree to which an implementation is out of sync with a team's understanding of what a product is intended to be. Many developers view such debt as emerging from primarily from poor architectural decisions (<a href="ernst">Ernst et al. 2015</a>). Over time, this debt can further result in organizational challenges (<a href="#khadka">Khadka et al. 2014</a>), making change even more difficult.</p>
+		<p>When encapsulation strategies fail, one can end up with what some affectionately call a "ball of mud" architecture or "spaghetti code". Ball of mud architectures have no apparent organization, which makes it difficult to comprehend how parts of its implementation interact. A more precise concept that can help explain this disorder is <b>cross-cutting concerns</b>, which are things like features and functionality that span multiple different components of a system, or even an entire system. There is some evidence that cross-cutting concerns can lead to difficulties in program comprehension and long-term design degradation (<a href="#walker">Walker et al. 2012</a>), all of which reduce productivity and increase the risk of defects. As long-lived systems get harder to change, they can take on <em>technical debt</em>, which is the degree to which an implementation is out of sync with a team's understanding of what a product is intended to be. Many developers view such debt as emerging from primarily from poor architectural decisions (<a href="ernst">Ernst et al. 2015</a>). Over time, this debt can further result in organizational challenges (<a href="#khadka">Khadka et al. 2014</a>), making change even more difficult.</p>
 		
 		<p>The preventative solution to this problems is to try to design architecture up front, mitigating the various risks that come from cross-cutting concerns (defects, low modifiability, etc.) (<a href="#fairbanks">Fairbanks 2010</a>). A popular method in the 1990's was the <a href="https://en.wikipedia.org/wiki/Unified_Modeling_Language">Unified Modeling Language</a> (UML), which was a series of notations for expressing the architectural design of a system before implementing it. Recent studies show that UML generally not used and generally not universal (<a href="#petre">Petre 2013</a>). More recent developers have investigated ideas of <b>architectural styles</b>, which are patterns of interactions and information exchange between encapsulated components. Some common architectural styles include:</p>