Fixed #12, citing trivial packages.

architecture.html

@@ -51,7 +51,7 @@
 
 		<p>The most common approach to dealing with both architectural mismatch and the changing of requirements over time is <b>refactoring</b>, which means changing the <em>architecture</em> of an implementation without changing its behavior. Refactoring is something most developers do as part of changing a system (<a href="#murphyhill">Murphy-Hill et al 2009</a>, <a href="#silva">Silva et al. 2016</a>). Refactoring code to eliminate mismatch and technical debt can simplify change in the future, saving time (<a href="#ng">Ng et al. 2006</a>) and prevent future defects (<a href="#kim">Kim et al. 2012</a>).
 		
-		<p>Research on the actual activity of software architecture is actually somewhat sparse. One of the more recent syntheses of this work is Petre et al.'s book, <em>Software Design Decoded</em> (<a href="#petre2">Petre et al. 2016</a>), which distills many of the practices and skills of software design into a set of succinct ideas. For example, the book states, "<em>Every design problem has multiple, if not infinite, ways of solving it. Experts strongly prefer simpler solutions over complex ones, for they know that such solutions are easier to understand and change in the future.</em>" These ideas, while powerful in their conciseness, are also grounded in substantial research on how software architects think and work.</p>
+		<p>Research on the actual activity of software architecture is actually somewhat sparse. One of the more recent syntheses of this work is Petre et al.'s book, <em>Software Design Decoded</em> (<a href="#petre2">Petre et al. 2016</a>), which distills many of the practices and skills of software design into a set of succinct ideas. For example, the book states, "<em>Every design problem has multiple, if not infinite, ways of solving it. Experts strongly prefer simpler solutions over complex ones, for they know that such solutions are easier to understand and change in the future.</em>" And yet, in practice, studies of how projects use APIs often show that developers do the exact opposite, building projects with dependencies on large numbers of sometimes trivial APIs. Some behavior suggests that while software <em>architects</em> like simplicity of implementation, software <em>developers</em> are often choosing whatever is easiest to build, rather than whatever is least risky to maintain over time (<a href="#abdalkareem">Abdalkareem 2017</a>).</p>
 		
 		<center class="lead"><a href="specifications.html">Next chapter: Specifications</a></center>
 
@@ -59,6 +59,8 @@
 
 		<small>
 
+		<p id="abdalkareem">Rabe Abdalkareem, Olivier Nourry, Sultan Wehaibi, Suhaib Mujahid, and Emad Shihab. 2017. <a href="https://doi.org/10.1145/3106237.3106267">Why do developers use trivial packages? An empirical case study on npm</a>. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017). ACM, New York, NY, USA, 385-395.</p>
+
 		<p id="bass">Len Bass, Bonnie E. John. 2003. <a href="http://www.sciencedirect.com/science/article/pii/S0164121202000766" target="_blank">Linking usability to software architecture patterns through general scenarios</a>. Journal of Systems and Software, Volume 66, Issue 3, Pages 187-197.</p>
 		<p id="beck">Kent Beck, Ron Crocker, Gerard Meszaros, John Vlissides, James O. Coplien, Lutz Dominick, and Frances Paulisch. 1996. <a href="https://doi.org/10.1109/ICSE.1996.493406" target="_blank">Industrial experience with design patterns</a>. In Proceedings of the 18th international conference on Software engineering (ICSE '96). IEEE Computer Society, Washington, DC, USA, 103-114.</p>
 		<p id="cito">J&uumlrgen Cito, Philipp Leitner, Thomas Fritz, and Harald C. Gall. 2015. <a href="https://doi.org/10.1145/2786805.2786826" target="_blank">The making of cloud applications: an empirical study on software development for the cloud</a>. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 393-403.</p>