Fixed #20, citing New York times article.

This commit is contained in:
Andy J. Ko 2019-04-02 14:05:15 -07:00 committed by GitHub
parent 8b1d5b2e7c
commit 97597de33f
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -30,7 +30,13 @@
<p>Because software engineering often times distributes work across multiple people, a fundamental challenge in software engineering is ensuring that everyone on a team has the same understanding of what is being built and why. In the seminal book &ldquo;The Mythical Man Month&rdquo;, Fred Brooks argued that good software needs to have <strong>conceptual integrity</strong>, both in how it is designed, but also how it is implemented (<a href="#brooks">Brooks 1995</a>). This is the idea that whatever vision of what is being built must stay intact, even as the building of it gets distributed to multiple people. When multiple people are responsible for implementing a single coherent idea, how can they ensure they all build the same idea?</p>
<p>The solution is effective communication. When communication is poor and teams are disconnected, software defects are the result (<a href="#bettenburg">Bettenburg & Hassan 2013</a>). The social relationships in a team also play a large role in structuring how projects evolve <a href="#zhou">(Zhou & Mockus 2011)</a>. Perhaps the most notable theory underlying these ideas is Conway's Law <a href="#conway">(Conway 1968)</a>, which argues that any designed system&mdash;software included&mdash;will reflect the social relationships behind its design. For example, look at any online banking website: the way the application is designed, how information is organized, the terminology that is used, and even the visual design is a reflection of how the teams inside that bank are organized and socially connected. Put simply, Conway observed that the architectural organization of the product resembled the organizational hierarchy of the teams that produced it.</p>
<p>
The solution is effective communication.
As <a href="https://www.nytimes.com/2017/08/12/upshot/techs-damaging-myth-of-the-loner-genius-nerd.html" target="_blank">some events in industry have shown, communication requires empathy</a>.
And research has shown that when communication is poor, teams become disconnected and produce software defects (<a href="#bettenburg">Bettenburg & Hassan 2013</a>).
Social relationships in a team also play a large role in structuring how projects evolve <a href="#zhou">(Zhou & Mockus 2011)</a>.
Perhaps the most notable theory underlying these ideas is Conway's Law <a href="#conway">(Conway 1968)</a>, which argues that any designed system&mdash;software included&mdash;will reflect the social relationships behind its design. For example, look at any online banking website: the way the application is designed, how information is organized, the terminology that is used, and even the visual design is a reflection of how the teams inside that bank are organized and socially connected. Put simply, Conway observed that the architectural organization of the product resembled the organizational hierarchy of the teams that produced it.
</p>
<p>Because communication is so central, software engineers are constantly seeking information to further their work, going to their coworkers' desks, emailing them, chatting via messaging platforms, and even using social media <a href="#ko">(Ko et al. 2007)</a>. Some of the information that developers are seeking is easier to find than others. For example, in the study I just cited, it was pretty trivial to find information about how wrote a line of code or whether a build was done, but when the information they needed resided in someone else's head (e.g., <em>why</em> a particular line of code was written), it was slow or often impossible to retrieve it. Sometimes it's not even possible to find out who has the information. Researchers have investigated tools for trying to quantify expertise by automatically analyzing the code that developers have written, building platforms to help developers search for other developers who might know what they need to know (<a href="#mockusherbsleb">Mockus & Herbsleb 2002</a>, <a href="#begel">Begel et al. 2010</a>).</p>