cooperative-software-develo.../process.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" />

		<title>Process</title>

	</head>
	<body>
		<p><a href="index.html">Back to table of contents</a></p>

		<img src="images/flow.jpg" class="img-responsive" />
		<small>Credit: public domain</small>

		<!-- UPDATE -->
		<h1>Process</h1>
		<div class="lead">Andrew J. Ko</div>

		<p>So you know what you're going to build and how you're going to build it. What process should you go about building it? Who's going to build what? What order should you build it in? How do you make sure everyone is in sync while you're building it? And most importantly, how to do you make sure you build well and on time? These are fundamental questions in software engineering with many potential answers. Unfortunately, we still don't know which of those answers are right.</p>

		<p>At the foundation of all of these questions are basic matters of <a href="https://en.wikipedia.org/wiki/Project_management" target="_blank">project management</a>: plan, execute, and monitor. But developers in the 1970's and on found that traditional project management ideas didn't seem to work. The earliest process ideas followed a "waterfall" model, in which a project begins by identifying requirements, writing specifications, implementing, testing, and releasing, all under the assumption that every stage could be fully tested and verified. (Recognize this? It's the order of topics we're discussing in this class!). Many managers seemed to like the waterfall model because it seemed structured and predictable; however, because most managers were originally software developers, they preferred a structured approach to project management (<a href="#weinberg">Weinberg 1982</a>). The reality, however, was that no matter how much verification one did of each of these steps, there always seemed to be more information in later steps that caused a team to reconsider it's earlier decision (e.g., imagine a customer liked a requirement when it was described in the abstract, but when it was actually built, they rejected it, because they finally saw what the requirement really meant).</p>

		<p>In 1988, Barry Boehm proposed an alternative to waterfall called the Spiral model (<a href="#boehm">Boehm 1988</a>): rather than trying to verify every step before proceeding to the next level of detail, <em>prototype</em> every step along the way, getting partial validation, iteratively converging through a series of prototypes toward both an acceptable set of requirements <em>and</em> an acceptable product. Throughout, risk assessment is key, encouraging a team to reflect and revise process based on what they are learning. What was important about these ideas were not the particulars of Boehm's proposed process, but the disruptive idea that iteration and process improvement are critical to engineering great software.</p>

		<img src="images/spiral.png" class="img-responsive" />

		<p>Around the same time, two influential books were published. Fred Brooks wrote <strong>The Mythical Man Month</strong> (<a href="#brooks">Brooks 1995</a>), a book about software project management, full of provocative ideas that would be tested over the next three decades, including the idea that adding more people to a project would not necessarily increase productivity. Tom DeMarco and Timothy Lister wrote another famous book, <strong>Peopleware: Productive Projects and Teams</strong> (<a href="#demarco">DeMarco 1987</a>), arguing that the major challenges in software engineering are human, not technical. Both of these works still represent some of the most widely-read statements of the problem of managing software development.</p>

		<p>These early ideas in software project management led to a wide variety of other discoveries about process. For example, organizations of all sizes can improve their process if they are very aware of what the people in the organization know, what it's capable of learning, and if it builds robust processes to actually continually improve process (<a href="dyba2">Dyb&#551; 2002</a>, <a href="#dyba">Dyb&#551; 2003</a>). This might mean monitoring the pace of work, incentivizing engineers to reflect on inefficiencies in process, and teaching engineers how to be comfortable with process change.</p>

		<p>Beyond process improvement, other factors emerged. For example, researchers discovered that critical to team productivity was <strong>awareness</strong> of teammates' work (<a href="#ko">Ko et al. 2007</a>). Teams need tools like dashboards to help make them aware of changing priorities and tools like feeds to coordinate short term work (<a href="#treude">Treude & Storey 2010</a>). Moreover, researchers found that engineers tended to favor non-social sources such as documentation for factual information, but social sources for information to support problem solving (<a href="milewski">Milewski 2007</a>). Decades ago, developers used tools like email and IRC for awareness; now they use tools like <a href="https://slack.com" target="_blank">Slack</a>, <a href="https://trello.com/" target="_blank">Trello</a>, <a href="http://github.com" target="_blank">GitHub</a>, and <a href="https://www.atlassian.com/software/jira" target="_blank">JIRA</a>, which have the same basic functionality, but are much more polished, streamlined, and customizable.</p>

		<p>In addition to awareness, <strong>ownership</strong> is a critical idea in process. This is the idea that for every line of code, someone is responsible for it's quality. The owner <em>might</em> be the person who originally wrote the code, but it could also shift to new team members. Studies of code ownership on Windows Vista and Windows 7 found that less a component had a clear owner, the more pre-release defects it had and the more post-release failures were reported by users (<a href="#bird">Bird et al. 2011</a>). This means that in addition to getting code written, having clear ownership and clear processes for transfer of ownership are key to functional correctness.</p>

		<p><strong>Pace</strong> is another factor that affects quality. Clearly, there's a tradeoff between how fast a team works and the quality of the product it can build. In fact, interview studies of engineers at Google, Facebook, Microsoft, Intel, and other large companies found that the pressure to reduce "time to market" harmed nearly every aspect of teamwork: the availability and discoverability of information, clear communication, planning, integration with others' work, and code ownership (<a href="#rubin">Rubin & Rinard 2016</a>). Not only did a fast pace reduce quality, but it also reduced engineers' personal satisfaction with their job and their work. I encountered similar issues as CTO of my startup: while racing to market, I was often asked to meet impossible deadlines with zero defects and had to constantly communicate to the other executives in the company why this was not possible (<a href="ko2">Ko 2017</a>).</p>

		<p>Because of the importance of awareness and communication, the <strong>distance</strong> between teammates is also a critical factor. This is most visible in companies that hire remote developers, building distributed teams. The primary motivation for doing this is to reduce costs or gain access to engineering talent that is distant from a team's geographical center, but over time, companies have found that doing so necessitates significant investments in travel and socialization to ensure quality, minimizing geographical, temporal and cultural separation (<a href="smite">Smite 2010</a>). Researchers have found that there appear to be fundamental tradeoffs between productivity, quality, and/or profits in these settings (<a href="#ramasubbu">Ramasubbu et al. 2011</a>). For example, more distance appears to lead to slower communication (<a href="#wagstrom">Wagstrom & Datta 2014</a>). Despite these tradeoffs, most rigorous studies of the cost of distributed development have found that when companies work hard to minimize temporal and cultural separation, the actual impact on defects was small (<a href="#kocaguneli">Kocaguneli et al. 2013</a>). Some researchers have begun to explore even more extreme models of distributed development, hiring contract developers to complete microtasks over a few days without hiring them as employees; early studies suggest that these models have the worst of outcomes, with greater costs, poor scalability, and more significant quality issues (<a href="#stol">Stol & Fitzgerald 2014</a>).</p>

		<p>While all of these research was being conducted, industry explored its own ideas about process, devising frameworks that addressed issues of distance, pace, ownership, awareness, and process improvement. Extreme Programming (<a href="beck">Beck 1999</a>) was one of these frameworks and it was full of ideas:</p>

		<ul>
			<li>Be iterative</li>
			<li>Do small releases</li>
			<li>Keep design simple</li>
			<li>Write unit tests</li>
			<li>Refactor to iterate</li>
			<li>Use pair programming</li>
			<li>Integrate continuously</li>
			<li>Everyone owns everything</li>
			<li>Use an open workspace</li>
			<li>Work sane hours</li>
		</ul>

		<p>Note that none of these had any empirical evidence to back them. Moreover, Beck described in his original proposal that these ideas were best for "<em>outsourced or in-house development of small- to medium-sized systems where requirements are vague and likely to change</em>", but as industry often does, it began hyping it as a universal solution to software project management woes and adopted all kinds of combinations of these ideas, adapting them to their existing processes. In reality, the value of XP appears to depend on highly project-specific factors (<a href="muller">M&uuml;ller & Padberk 2013</a>), while the core ideas that industry has adopted are valuing feedback, communication, simplicity, and respect for individuals and the team (<a href="sharp">Sharp & Robinson 2004</a>). Researchers continue to investigate the merits of the list above; for example, numerous studies have investigated the effects of pair programming on defects, finding small but measurable benefits (<a href="#dibella">di Bella et al. 2012</a>)</p>

		<p>At the same time, Beck began also espousing the idea of <a href="http://agilemanifesto.org/" target="_blank">"Agile" methods</a>, which celebrated many of the values underlying Extreme Programming, such as focusing on individuals, keeping things simple, collaborating with customers, and being iterative. This idea of begin agile was even more popular and spread widely in industry and research, even though many of the same ideas appeared much earlier in Boehm's work on the Spiral model. Researchers found that Agile methods can increase developer enthusiasm (<a href="syed">Syed-Abdulla et al. 2006</a>), that agile teams need different roles such as Mentor, Co-ordinator, Translator, Champion, Promoter, and Terminator (<a href="#hoda">Hoda et al. 2010</a>), and that teams are combing agile methods with all kinds of process ideas from other project management frameworks such as <a href="https://en.wikipedia.org/wiki/Scrum_(software_development)">Scrum</a> (meet daily to plan work, plan two-week sprints, maintain a backlog of work) and Kanban (visualize the workflow, limit work-in-progress, manage flow, make policies explicit, and implement feedback loops) (<a href="#al-baik">Al-Baik & Miller 2015</a>). I don't define any of these ideas here because there aren't standard definitions to share.</p>

		<p>Ultimately, all of this energy around process ideas in industry is exciting, but disorganized. None of these efforts really get to the core of what makes software projects difficult to manage. One effort in research to get to this core by contributing new theories that explain these difficulties. The first is Herbsleb's <strong>Socio-Technical Theory of Coordination (STTC)</strong>. The idea of the theory is quite simple: <em>technical dependencies</em> in engineering decisions (e.g., this function calls this other function, this data type stores this other data type) define the <em>social constraints</em> that the organization must solve in a variety of ways to build and maintain software (<a href="#herbslebmockus">Herbsleb & Mockus 2003</a>, <a href="#herbsleb">Herbsleb 2016</a>). The better the organization builds processes and awareness tools to ensure that the people who own those engineering dependencies are communicating and aware of each others' work, the fewer defects that will occur. Herbsleb referred this alignment as <em>sociotechnical congruence</em>, and conducted a number of studies demonstrating its predictive and explanatory power.</p>

		<p>In my recent work (<a href="#ko2">Ko 2017</a>), I extend this idea to congruence with beliefs about <em>product</em> value, claiming that successful software products require the constant, collective communication and agreement of a coherent proposition of a product's value across UX, design, engineering, product, marketing, sales, support, and even customers. A team needs to achieve Herbsleb's sociotechnical congruence to have a successful product, but that alone is not enough: the rest of the organization has to have a consistent understanding of what is being built and why, even as that understanding evolves over time.</p>

		<center class="lead"><a href="comprehension.html">Next chapter: Comprehension</a></center>

		<h2>Further reading</h2>

		<small>

		<p id="al-baik">Al-Baik, O., & Miller, J. (2015). <a href="https://link.springer.com/article/10.1007/s10664-014-9340-x" target="_blank">The kanban approach, between agility and leanness: a systematic review</a>. Empirical Software Engineering, 20(6), 1861-1897.</p>
		<p id="beck">Beck, K. (1999). <a href="http://ieeexplore.ieee.org/abstract/document/796139/" target="_blank">Embracing change with extreme programming</a>. Computer, 32(10), 70-77.</p>
		<p id="bird">Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu. 2011. <a href="http://dx.doi.org/10.1145/2025113.2025119" target="_blank">Don't touch my code! Examining the effects of ownership on software quality</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, 4-14.</a>
		<p id="boehm">Boehm, B. W. (1988). <a href="http://ieeexplore.ieee.org/abstract/document/59/" target="_blank">A spiral model of software development and enhancement</a>. Computer, 21(5), 61-72.</p>
		<p id="brooks">Brooks, F.P. (1995). <a href="https://books.google.com/books?id=Yq35BY5Fk3gC" target="_blank">The Mythical Man Month</a>.</p>
		<p id="dibella">di Bella, E., Fronza, I., Phaphoom, N., Sillitti, A., Succi, G., & Vlasenko, J. (2013). <a href="https://doi.org/10.1109/TSE.2012.68">Pair Programming and Software Defects--A Large, Industrial Case Study</a>. IEEE Transactions on Software Engineering, 39(7), 930-953.</p>
		<p id="demarco">DeMarco, T. and Lister, T. (1987). <a href="https://books.google.com/books?id=TVQUAAAAQBAJ" target="_blank">Peopleware: Productive Projects and Teams</a>.</p>
		<p id="dyba">Tore Dyb&#551;. 2003. <a href="http://dx.doi.org/10.1145/940071.940092" target="_blank">Factors of software process improvement success in small and large organizations: an empirical study in the scandinavian context</a>. In Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11). ACM, New York, NY, USA, 148-157.</p>
		<p id="dyba2">Dyb&#551;, T. (2002). <a href="https://link.springer.com/article/10.1023/A:1020535725648" target="_blank">Enabling software process improvement: an investigation of the importance of organizational issues</a>. Empirical Software Engineering, 7(4), 387-390.</p>
		<p id="herbslebmockus">James D. Herbsleb and Audris Mockus. 2003. <a href="http://dx.doi.org/10.1145/940071.940091" target="_blank">Formulation and preliminary test of an empirical theory of coordination in software engineering</a>. In Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11). ACM, New York, NY, USA, 138-137.</p>
		<p id="herbsleb">James Herbsleb. 2016. <a href="https://doi.org/10.1145/2950290.2994160" target="_blank">Building a socio-technical theory of coordination: why and how</a>. In Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2016). ACM, New York, NY, USA, 2-10.</p>
		<p id="hoda">Rashina Hoda, James Noble, and Stuart Marshall. 2010. <a href="https://doi.org/10.1145/1806799.1806843" target="_blank">Organizing self-organizing teams</a>. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1 (ICSE '10), Vol. 1. ACM, New York, NY, USA, 285-294.</p>
		<p id="ko">Andrew J. Ko, Robert DeLine, and Gina Venolia. 2007. <a href="http://dx.doi.org/10.1109/ICSE.2007.45" target="_blank">Information Needs in Collocated Software Development Teams</a>. In Proceedings of the 29th international conference on Software Engineering (ICSE '07). IEEE Computer Society, Washington, DC, USA, 344-353.</p>
		<p id="ko2">Andrew J. Ko (2017). <a href="http://faculty.washington.edu/ajko/papers/Ko2017AnswerDashReflection.pdf" target="_blank">A Three-Year Participant Observation of Software Startup Software Evolution</a>. International Conference on Software Engineering (ICSE), Software Engineering in Practice, to appear.</a>
		<p id="kocaguneli">Ekrem Kocaguneli, Thomas Zimmermann, Christian Bird, Nachiappan Nagappan, and Tim Menzies. 2013. <a href="https://doi.org/10.1109/ICSE.2013.6606637" target="_blank">Distributed development considered harmful?</a> In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13). IEEE Press, Piscataway, NJ, USA, 882-890.</p>
		<p id="milewski">Milewski, A. E. (2007). <a href="https://link.springer.com/article/10.1007/s10664-007-9036-6" target="_blank">Global and task effects in information-seeking among software engineers</a>. Empirical Software Engineering, 12(3), 311-326.
		<p id="muller">Matthias M. M&uumlller and Frank Padberg. 2003. <a href="http://dx.doi.org/10.1145/940071.940094" tar target="_blank">On the economic evaluation of XP projects</a>. In Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-11). ACM, New York, NY, USA, 168-177.</p>
		<p id="ramasubbu">Narayan Ramasubbu, Marcelo Cataldo, Rajesh Krishna Balan, and James D. Herbsleb. 2011. <a href="https://doi.org/10.1145/1985793.1985830" target="_blank">Configuring global software teams: a multi-company analysis of project productivity, quality, and profits</a>. In Proceedings of the 33rd International Conference on Software Engineering (ICSE '11). ACM, New York, NY, USA, 261-270.</p>		<p id="sharp">Sharp, H., & Robinson, H. (2004). <a href="https://doi.org/10.1023/B:EMSE.0000039884.79385.54">An ethnographic study of XP practice</a>. Empirical Software Engineering, 9(4), 353-375.</p>
		<p id="rubin">Julia Rubin and Martin Rinard. 2016. <a href="https://doi.org/10.1145/2884781.2884871" target="_blank">The challenges of staying together while moving fast: an exploratory study</a>. In Proceedings of the 38th International Conference on Software Engineering (ICSE '16). ACM, New York, NY, USA, 982-993.</p>
		<p id="smite">Smite, D., Wohlin, C., Gorschek, T., & Feldt, R. (2010). <a href="https://link.springer.com/article/10.1007/s10664-009-9123-y" target="_blank">Empirical evidence in global software engineering: a systematic review</a>. Empirical software engineering, 15(1), 91-118.</p>
		<p id="stol">Klaas-Jan Stol and Brian Fitzgerald. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568249" target="_blank">Two's company, three's a crowd: a case study of crowdsourcing software development</a>. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 187-198.</p>
		<p id="syed">Syed-Abdullah, S., Holcombe, M., & Gheorge, M. (2006). <a href="https://link.springer.com/article/10.1007%2Fs10664-006-5968-5" target="_blank">The impact of an agile methodology on the well being of development teams</a>. Empirical Software Engineering, 11(1), 143-167.</p>
		<p id="treude">Christoph Treude and Margaret-Anne Storey. 2010. <a href="http://dx.doi.org/10.1145/1806799.1806854" target="_blank">Awareness 2.0: staying aware of projects, developers and tasks using dashboards and feeds</a>. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1 (ICSE '10), Vol. 1. ACM, New York, NY, USA, 365-374.</p>
		<p id="wagstrom">Patrick Wagstrom and Subhajit Datta. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568279" target="_blank">Does latitude hurt while longitude kills? Geographical and temporal separation in a large scale software development project</a>. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 199-210.</p>
		<p id="weinberg">Gerald M. Weinberg. 1982. <a href="http://dl.acm.org/citation.cfm?id=807743" target="_blank">Over-structured management of software engineering</a>. In Proceedings of the 6th international conference on Software engineering (ICSE '82). IEEE Computer Society Press, Los Alamitos, CA, USA, 2-8.</p>

		</small>

		<h2>Podcasts</h2>

		<small>

		<p>Software Engineering Daily (2016). <a href="https://softwareengineeringdaily.com/2016/04/06/git-workflows-tim-pettersen/" target="_blank">Git Workflows with Tim Pettersen</a>.</p>
		<p>Software Engineering Daily (2017). <a href="https://softwareengineeringdaily.com/2017/02/08/engineering-management-with-mike-borozdin/" target="_blank">Engineering Management with Mike Borozdin</a>.</p>
		<p>Software Engineering Daily (2017). <a href="https://softwareengineeringdaily.com/2016/09/22/tech-leadership-with-jeff-norris/" target="_blank">Tech Leadership with Jeff Norris</a>.</p>

		</small>

	</body>

</html>