mirror of
https://github.com/amyjko/cooperative-software-development
synced 2024-12-27 21:58:55 +01:00
85 lines
13 KiB
HTML
85 lines
13 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
|
|
|
||
|
|
<!-- Latest compiled and minified CSS -->
|
||
|
|
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">
|
||
|
|
|
||
|
|
<!-- Optional theme -->
|
||
|
|
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css" integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp" crossorigin="anonymous">
|
||
|
|
|
||
|
|
<!-- Latest compiled and minified JavaScript -->
|
||
|
|
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
|
||
|
|
|
||
|
|
<link rel="stylesheet" href="style.css" />
|
||
|
|
|
||
|
|
<!-- UPDATE -->
|
||
|
|
<title>Productivity</title>
|
||
|
|
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<p><a href="index.html">Back to table of contents</a></p>
|
||
|
|
|
||
|
|
<img src="images/productivity.jpg" class="img-responsive" />
|
||
|
|
<small>Credit: unknown</small>
|
||
|
|
|
||
|
|
<h1>Productivity</h1>
|
||
|
|
<div class="lead">Andrew J. Ko</div>
|
||
|
|
|
||
|
|
<p>When we think of productivity, we usually have a vague concept of a rate of work per unit time. Where it gets tricky is in defining "work". On an individual level, work can be easier to define, because developers often have specific concrete tasks that they're assigned. But until they're not, it's not really easy to define progress (well, it's not that easy to define "done" sometimes either, but that's a topic for a later chapter). When you start considering work at the scale of a team or an organization, productivity gets even harder to define, since an individual's productivity might be increased by ignoring every critical request from a teammate, harming the team's overall productivity.</p>
|
||
|
|
|
||
|
|
<p>Despite the challenge in defining productivity, there are numerous factors that affect productivity. For example, at the individual level, having the right tools can result in an order of magnitude difference in speed at accomplishing a task. One study I ran found that developers using the Eclipse IDE spent a third of their time just physically navigating between source files (<a href="#koide">Ko et al. 2005</a>). With the right navigation aids, developers could be writing code and fixing bugs 30% faster. In fact, some tools like Mylyn automatically bring relevant code to the developer rather than making them navigate to it, greatly increasing the speed which with developers can accomplish a task (<a href="#kersten">Kersten & Murphy 2006</a>). Long gone are the days when developers should be using bare command lines and text editors to write code: IDEs can and do greatly increase productivity when used and configured with speed in mind.</p>
|
||
|
|
|
||
|
|
<p>That said, productivity is not just about individual developers. Because communication is a key part of team productivity, an individual's productivity is as much determined by their ability to collaborate and communicate with other developers. In a study spanning dozens of interviews with senior software engineerings, Li et al. found that the majority of critical attributes for software engineering skill (productivity included) concerned their interpersonal skills, their communication skills, and their ability to be resourceful within their organization (<a href="#li">Li et al. 2015</a>). Similarly, LaToza et al. found that the primary bottleneck in productivity was communication with teammates, primarily because waiting for replies was slower than just looking something up (<a href="#latoza">LaToza et al. 2006</a>). Of course, looking something up has its own problems. While StackOverflow is an incredible resource for missing documentation (<a href="#mamykina">Mamykina et al. 2001</a>), it also is full of all kinds of misleading and incorrect information contributed by developers without sufficient expertise to answer questions (<a href="#barua">Barua et la. 2014</a>). Finally, because communication is such a critical part of retrieving information, adding more developers to a team has surprising effects. One study found that adding people to a team slowly enough to allow them to onboard effectively could increase reduce defects, but adding them too fast led to increases in defects (<a href="#meneely">Meneely et al. 2011</a>).</p>
|
||
|
|
|
||
|
|
<p>Another dimension of productivity is learning. Great engineers are resourceful, quick learners (<a href="#li">Li et al. 2015</a>); new engineers must be even more resourceful, even though their instincts are often to hide their lack of expertise from exactly the people they need help from (<a href="#begel">Begel & Simon 2008</a>). Experienced developers know that learning is important and now rely heavily on social media such as Twitter to follow industry changes, build learning relationships, and discover new concepts and platforms to learn (<a href="singer">Singer et al. 2012</a>).</p>
|
||
|
|
|
||
|
|
<p>Unfortunately, learning is no easy task. One of my earliest studies as a researcher investigated the barriers to learning new programming languages and systems, finding six distinct types of content that are challenging (<a href="#ko">Ko & Myers 2004</a>). To use a programming platform successfully, they need to overcome <em>design</em> barriers, which are the abstract computational problems that must be solved, independent of the languages and APIs. They need to overcome <em>selection</em> barriers, which involve finding the right abstractions or APIs to achieve the design they have identified. They need to overcome <em>use</em> and <em>coordination</em> barriers, which involve operating and coordinating different parts of a language or API together to achieve novel functionality. They need to overcome <em>comprehension</em> barriers, which involve knowing what can go wrong when using part of a language or API. And finally, they need to overcome <em>information</em> barriers, which are posed by the limited ability of tools to inspect a program's behavior at runtime during debugging. Every single one of these barriers has its own challenges, and developers encounter them every time they are learning a new platform, regardless of how much expertise they have.</p>
|
||
|
|
|
||
|
|
<p>Aside from individual and team factors, productivity is also influenced by the particular features of a project's code and how the project is managed (<a href="#vosburgh">Vosburgh et al. 1984</a>, <a href="#demarco">DeMarco & Lister 1985</a>). In fact, these might actually be the <em>biggest</em> factors in determining developer productivity. This means that even a developer that is highly productive individually cannot rescue a team that is poorly structured working on poorly architected code. This might be why highly productive developers are so difficult to recruit to poorly managed teams.</p>
|
||
|
|
|
||
|
|
<center class="lead"><a href="quality.html">Next chapter: Quality</a></center>
|
||
|
|
|
||
|
|
<h2>Further reading</h2>
|
||
|
|
|
||
|
|
<small>
|
||
|
|
|
||
|
|
<p id="barua">Barua, A., Thomas, S. W., & Hassan, A. E. (2014). <a href="http://link.springer.com/article/10.1007/s10664-012-9231-y" target="_blank">What are developers talking about? an analysis of topics and trends in stack overflow</a>. Empirical Software Engineering, 19(3), 619-654.</p>
|
||
|
|
<p id="begel">Begel, A., & Simon, B. (2008, September). <a href="http://dl.acm.org/citation.cfm?id=1404522" target="_blank">Novice software developers, all over again</a>. In Proceedings of the Fourth international Workshop on Computing Education Research (pp. 3-14). ACM.</p>
|
||
|
|
<p id="casalnuovo">Casey Casalnuovo, Bogdan Vasilescu, Premkumar Devanbu, and Vladimir Filkov. 2015. <a href="https://doi.org/10.1145/2786805.2786854" target="_blank">Developer onboarding in GitHub: the role of prior social links and language experience</a>. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 817-828.</p>
|
||
|
|
<p id="chong">Jan Chong and Tom Hurlbutt. 2007. <a href="http://dx.doi.org/10.1109/ICSE.2007.87" target="_blank">The Social Dynamics of Pair Programming</a>. In Proceedings of the 29th international conference on Software Engineering (ICSE '07). IEEE Computer Society, Washington, DC, USA, 354-363.</p>
|
||
|
|
<p id="demarco">Tom DeMarco and Tim Lister. 1985. <a href="http://dl.acm.org/citation.cfm?id=319651" target="_blank">Programmer performance and the effects of the workplace</a>. In Proceedings of the 8th international conference on Software engineering (ICSE '85). IEEE Computer Society Press, Los Alamitos, CA, USA, 268-272.</p>
|
||
|
|
<p id="duala">Ekwa Duala-Ekoko and Martin P. Robillard. 2012. <a href="http://dl.acm.org/citation.cfm?id=2337255" target="_blank">Asking and answering questions about unfamiliar APIs: an exploratory study</a>. In Proceedings of the 34th International Conference on Software Engineering (ICSE '12). IEEE Press, Piscataway, NJ, USA, 266-276.</p>
|
||
|
|
<p id="li">Paul Luo Li, Andrew J. Ko, and Jiamin Zhu. 2015. <a href="http://dl.acm.org/citation.cfm?id=2818839" target="_blank">What makes a great software engineer?</a>. In Proceedings of the 37th International Conference on Software Engineering - Volume 1 (ICSE '15), Vol. 1. IEEE Press, Piscataway, NJ, USA, 700-710.</p>
|
||
|
|
<p id="johnson">Brittany Johnson, Rahul Pandita, Emerson Murphy-Hill, and Sarah Heckman. 2015. <a href="https://doi.org/10.1145/2786805.2803197" target="_blank">Bespoke tools: adapted to the concepts developers know</a>. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 878-881.</p>
|
||
|
|
<p id="kersten">Mik Kersten and Gail C. Murphy. 2006. <a href="http://dx.doi.org/10.1145/1181775.1181777" target="_blank">Using task context to improve programmer productivity</a>. In Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering (SIGSOFT '06/FSE-14). ACM, New York, NY, USA, 1-11.</p>
|
||
|
|
<p id="ko">Ko, A. J., Myers, B. A., & Aung, H. H. (2004, September). <a href="http://ieeexplore.ieee.org/abstract/document/1372321/" target="_blank">Six learning barriers in end-user programming systems</a>. In Visual Languages and Human Centric Computing, 2004 IEEE Symposium on (pp. 199-206). IEEE.</p>
|
||
|
|
<p id="koide">Andrew J. Ko, Htet Aung, and Brad A. Myers. 2005. <a href="http://ieeexplore.ieee.org/abstract/document/1553555/" target="_blank">Eliciting design requirements for maintenance-oriented IDEs: a detailed study of corrective and perfective maintenance tasks</a>. In Proceedings of the 27th international conference on Software engineering (ICSE '05). ACM, New York, NY, USA, 126-135.</p>
|
||
|
|
<p id="latoza">Thomas D. LaToza, Gina Venolia, and Robert DeLine. 2006. <a href="http://dx.doi.org/10.1145/1134285.1134355" target="_blank">Maintaining mental models: a study of developer work habits</a>. In Proceedings of the 28th international conference on Software engineering (ICSE '06). ACM, New York, NY, USA, 492-501.</p>
|
||
|
|
<p id="mamykina">Mamykina, L., Manoim, B., Mittal, M., Hripcsak, G., & Hartmann, B. (2011, May). <a href="http://dl.acm.org/citation.cfm?id=1979366" target="_blank">Design lessons from the fastest q&a site in the west</a>. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 2857-2866).</p>
|
||
|
|
<p id="meneely">Andrew Meneely, Pete Rotella, and Laurie Williams. 2011. <a href="http://dx.doi.org/10.1145/2025113.2025128" target="_blank">Does adding manpower also affect quality? An empirical, longitudinal analysis</a>. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE '11). ACM, New York, NY, USA, 81-90.</p>
|
||
|
|
<p id="meyer">André N. Meyer, Thomas Fritz, Gail C. Murphy, and Thomas Zimmermann. 2014. <a href="http://dx.doi.org/10.1145/2635868.2635892" target="_blank">Software developers' perceptions of productivity</a>. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014). ACM, New York, NY, USA, 19-29.</p>
|
||
|
|
<p id="singer">Leif Singer, Fernando Figueira Filho, and Margaret-Anne Storey. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568305" target="_blank">Software engineering at the speed of light: how developers stay current using twitter</a>. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 211-221.</p>
|
||
|
|
<p id="stylos">Jeffrey Stylos and Brad A. Myers. 2008. <a href="http://dx.doi.org/10.1145/1453101.1453117">The implications of method placement on API learnability</a>. In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (SIGSOFT '08/FSE-16). ACM, New York, NY, USA, 105-112.</p>
|
||
|
|
<p id="vosburgh">J. Vosburgh, B. Curtis, R. Wolverton, B. Albert, H. Malec, S. Hoben, and Y. Liu. 1984. <a href="http://dl.acm.org/citation.cfm?id=801963" target="_blank">Productivity factors and programming environments</a>. In Proceedings of the 7th international conference on Software engineering (ICSE '84). IEEE Press, Piscataway, NJ, USA, 143-152.</p>
|
||
|
|
|
||
|
|
</small>
|
||
|
|
|
||
|
|
<h2>Podcasts</h2>
|
||
|
|
|
||
|
|
<small>
|
||
|
|
|
||
|
|
<p>Software Engineering Daily, <a href="https://softwareengineeringdaily.com/2016/11/09/reflections-of-an-old-programmer-with-ben-northrup/">Reflections of an Old Programmer</a></p>
|
||
|
|
<p>Software Engineering Daily, <a href="https://softwareengineeringdaily.com/2015/12/23/hiring-engineers-with-ammon-bartram/">Hiring Engineers with Ammon Bartram</a></p>
|
||
|
|
|
||
|
|
</small>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|
||
|
|
|
||
|
|
|
||
|
|
|