Fixed #22, citing Atlantic article.

organizations.html

@@ -15,7 +15,6 @@
 		
 		<link rel="stylesheet" href="style.css" />
 
-		<!-- UPDATE -->
 		<title>Software engineering organizations</title>
 		
 	</head>
@@ -23,7 +22,7 @@
 		<p><a href="index.html">Back to table of contents</a></p>
 
 		<img src="images/team.jpg" class="img-responsive" />
-		<small>Credit: Andrew J. Ko</small>
+		<small>A software engineering team hard at work. Credit: Andrew J. Ko</small>
 		
 		<h1>Software organizations</h1>
 		<div class="lead">Andrew J. Ko</div>
@@ -34,7 +33,7 @@
 		
 		<p>Organizations are a much bigger topic than I could possibly address here. To deeply understand them, you'd need to learn about <a href="https://en.wikipedia.org/wiki/Organizational_studies" target="_blank">organizational studies</a>, <a href="https://en.wikipedia.org/wiki/Organizational_behavior" target="_blank">organizational behavior</a>, <a href="https://en.wikipedia.org/wiki/Information_system" target="_blank">information systems</a>, and business in general.</p>
 		
-		<p>The subset of this knowledge that's critical to understand about software engineering is limited to a few important concepts. The first and most important concept is that even in software organizations, the point of the company is rarely to make software; it's to provide <em>value</em> <a href="#osterwalder">(Osterwalder et al. 2015)</a>. Software is sometimes the central means to providing that value, but more often than not, it's the <em>information</em> flowing through that software that's the truly valuable piece. <a href="requirements.html">Requirements</a>, which will be discussed in more detail soon, help engineers organize how software will provide value.</p>
+		<p>The subset of this knowledge that's critical to understand about software engineering is limited to a few important concepts. The first and most important concept is that even in software organizations, the point of the company is rarely to make software; it's to provide <strong>value</strong> <a href="#osterwalder">(Osterwalder et al. 2015)</a>. Software is sometimes the central means to providing that value, but more often than not, it's the <em>information</em> flowing through that software that's the truly valuable piece. <a href="requirements.html">Requirements</a>, which we will discuss in a later chapter, help engineers organize how software will provide value.</p>
 		
 		<p>The individuals in a software organization take on different roles to achieve that value. These roles are sometimes spread across different people and sometimes bundled up into one person, depending on how the organization is structured, but the roles are always there. Let's go through each one in detail so you understand how software engineers relate to each role.</>
 		
@@ -54,11 +53,11 @@
 		<p>There are other roles you might be thinking of that I haven't mentioned:</p>
 		
 		<ul>
-			<li><b>Managers</b> exist in all roles when teams get to a certain size, helping to move information from between higher and lower parts of an organization. Even <em>engineering</em> managers are primarily focused on organizing and prioritizing work, and not doing engineering (<a href="#kalliamvakou">Kalliamvakou et al. 2018)</a>.</li>
+			<li><strong>Engineering managers</strong> exist in all roles when teams get to a certain size, helping to move information from between higher and lower parts of an organization. Even <em>engineering</em> managers are primarily focused on organizing and prioritizing work, and not doing engineering (<a href="#kalliamvakou">Kalliamvakou et al. 2018)</a>. Much of their time is also spent ensuring every engineer has what they need to be productive, while also managing coordination and interpersonal conflict between engineers.</li>
 			<li><b>Data scientists</b>, although a new role, typically <em>facilitate</em> decision making on the part of any of the roles above <a href="#begel">(Begel & Zimmermann 2014)</a>. They might help engineers find bugs, marketers analyze data, track sales targets, mine support data, or inform design decisions. They're experts at using data to accelerate and improve the decisions made by the roles above.</li>
 			<li><b>Researchers</b>, also called user researchers, also help people in a software organization make decisions, but usually <em>product</em> decisions, helping marketers, sales, and product managers decide what products to make and who would want them. In many cases, they can complement the work of data scientists, <a href="https://www.linkedin.com/pulse/ux-research-analytics-yann-riche?trk=prof-post" target="_blank">providing qualitative work to triangulate quantitative data</a>.</li>
 		</ul>
-		<p>Every decision made in a software team is under uncertainty, and so another important concept in organizations is <strong>risk</strong> <a href="#boehm">(Boehm 1991)</a>. It's rarely possible to predict the future, and so organizations must take risks. Much of an organization's function is to mitigate the consequences of risks. Data scientists and researchers mitigate risk by increasing confidence in an organization's understanding of the market and its consumers. Engineers manage risk by trying to avoid defects and moving fast.</p>
+		<p>Every decision made in a software team is under uncertainty, and so another important concept in organizations is <strong>risk</strong> <a href="#boehm">(Boehm 1991)</a>. It's rarely possible to predict the future, and so organizations must take risks. Much of an organization's function is to mitigate the consequences of risks. Data scientists and researchers mitigate risk by increasing confidence in an organization's understanding of the market and its consumers. Engineers manage risk by trying to avoid defects. Of course, as many popular outlets on software engineering have begun to discover, when software fails, it usually "did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing." (<a href="https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/">Somers 2017</a>).</p>
 		
 		<p>Open source communities are organizations too. The core activities of design, engineering, and support still exist in these, but how much a community is engaged in marketing and sales depends entirely on the purpose of the community. Big, established open source projects like <a href="https://mozilla.org" target="_blank">Mozilla</a> have revenue, buildings, and a CEO, and while they don't sell anything, they do market. Others like Linux <a href="#lee">(Lee & Cole 2013)</a> rely heavily on contributions both from volunteers <a href="#ye">(Ye & Kishida 2003)</a>, but also paid employees from companies that depend on Linux, like IBM, Google, and others. In these settings, there are still all of the challenges that come with software engineering, but fewer of the constraints that come from a for-profit or non-profit motive.</p>
 		
@@ -94,6 +93,8 @@
 
 		<p id="osterwalder">A. Osterwalder, Y. Pigneur, G. Bernarda, & A. Smith (2015). <a href="https://books.google.com/books?id=jgu5BAAAQBAJ" target="_blank">Value proposition design: how to create products and services customers want</a>. John Wiley & Sons.</p>
 
+		<p>Somers, James (2017). <a href="https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/">The Coming Software Apocalypse</a>. The Atlantic Monthly.</p>
+
 		<p id="ye">Yunwen Ye and Kouichi Kishida. 2003. <a href="http://dl.acm.org/citation.cfm?id=776867" target="_blank">Toward an understanding of the motivation Open Source Software developers</a>. In Proceedings of the 25th International Conference on Software Engineering (ICSE '03). IEEE Computer Society, Washington, DC, USA, 419-429.
 
 		<script type="text/javascript">