Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-25 21:58:15 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed #9, adding productivity at work paper.

Browse source
This commit is contained in:
Andy J. Ko 2019-04-02 14:33:33 -07:00 committed by GitHub
parent 3b7fe7f54e
commit 07fb6f00a5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
productivity.html
View file

@ -30,7 +30,20 @@
<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>
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>
Of course, individual productivity is about more than just tools.
Studies of workplace productivity show that developers have highly fragmented days, interrupted by meetings, emails, coding, and non-work distractions (<a href="meyer">Meyer et al. 2017</a>).
These interruptions are often viewed negatively from an individual perspective, but may be highly valuable from a team and organizational perspective.
</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 engineers, 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 reduce defects, but adding them too fast led to increases in defects (<a href="#meneely">Meneely et al. 2011</a>).</p>
@ -82,7 +95,7 @@
<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&eacute 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="meyer">Meyer, A. N., Barton, L. E., Murphy, G. C., Zimmermann, T., & Fritz, T. (2017). <a href="https://doi.org/10.1109/TSE.2017.2656886">The work life of developers: Activities, switches and perceived productivity</a>. IEEE Transactions on Software Engineering, 43(12), 1178-1193.</p>
<p id="sedano">Sedano, T., Ralph, P., & P&eacute;raire, C. (2017, May). <a href="http://dl.acm.org/citation.cfm?id=3097385">Software development waste</a>. In Proceedings of the 39th International Conference on Software Engineering (pp. 130-140). IEEE Press.</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>