A few rewordings

README.md

@@ -9,11 +9,11 @@ of the paper.
 
 We have long discussed how pair programming, among several benefits, accelerates knowledge sharing, ensures
 collective code ownership, and increases overall developer productivity.
-These benefits outweigh the previously assumed decrease in velocity and high cost due to having two people do
+These benefits outweigh the previously assumed decrease in velocity and high cost of to having two people do
 the work of one.
-Recently, we have learned that pairing does not negatively impact velocity, and can even improve velocity
-significantly, even in the short term.
-We complete more features faster by pairing because the code reviews happen in parallel, rather than asynchronously.
+We have shown that pairing does not negatively impact velocity, and in fact improves velocity significantly even in the
+short term.
+We complete more features faster by pairing because the code reviews happen in real time, rather than asynchronously.
 
 ## Summary 
 

pairing.tex

@@ -25,10 +25,10 @@
     \begin{abstract}
         We have long discussed how pair programming, among several benefits, accelerates knowledge sharing, ensures
         collective code ownership, and increases overall developer productivity~\cite{fowler:pairing}.
-        These benefits outweigh the previously assumed decrease in velocity and high cost due to having two people do
+        These benefits outweigh the previously assumed decrease in velocity and high cost of having two people do
         the work of one.
         Recently, we have been able to show that pairing does not negatively impact velocity.
-        On the contrary, pairing can improve velocity significantly, even in the short term.
+        On the contrary, pairing can improve velocity significantly even in the short term.
         We complete more features faster by pairing because the code reviews happen in real time rather than
         asynchronously.
     \end{abstract}
@@ -42,20 +42,20 @@
     Pair programming, or having the two developers work side-by-side on a common problem or set of features, is one form
     of this collaboration.
 
-    However, once developers have a solid understanding of product domain and technology stack, the question quickly
-    becomes: What happens when individuals understand both product domain and technology?
+    However, once developers have a solid understanding of product domain and technology stack, the question changes.
+    What happens when individuals understand both product domain and technology?
     Should they still pair?
 
     The simple answer might be yes, because both domain and technology are constantly changing and there is always more
     to learn.
     In addition, the benefits of collective ownership alone might lead individuals to continue to pair.
 
     \begin{displayquote}[\cite{fowler:pairing}][\textit{Birgitta Böckeler and Nina Siessegger}]
-        ``{[Pairing]} increases the chances that anyone on the team feels comfortable changing the code almost anywhere."
+        ``{[Pairing]} increases the chances that anyone on the team feels comfortable changing the code almost anywhere.''
     \end{displayquote}
 
     Many organizations attempt to layer on processes to ensure code quality and security, however in practice this
-    creates an increase in feedback cycles that have the opposite effect.
+    creates an increase in the length of feedback cycles that has the opposite effect.
     In fact, research has found that lightweight change approval processes are the best way to ensure stability in a
     software product.
 
@@ -65,12 +65,12 @@
     In short, approval by an external body (such as a manager or CAB) simply doesn't work to increase the stability of
     production systems, measured by the time to restore service and change fail rate.
     However, it certainly slows things down.
-    It is, in fact, worse than having no change approval process at all."
+    It is, in fact, worse than having no change approval process at all.''
     \end{displayquote}
 
     In effect, pair programming promotes this concept of lightweight change approval process with fast feedback cycles.
-    This alone would be an argument to continue to pair, however we have recently discovered that the impact is most
-    effected by how easy the work is to parallelize.
+    This alone would be an argument to continue to pair, however we have recently discovered that the largest impact
+    comes from the ability to work fast with fewer parallel workstreams.
 
 
     \section{Discussion}\label{sec:discussion}
@@ -79,8 +79,8 @@
 
     Consider a typical 8-hour day, and assume that we have two features: $F1$, which takes four hours to complete, and
     $F2$, which takes three hours to complete.
-    As is common, these features must be completed sequentially (starting feature two is dependent on completing feature
-    one successfully).
+    As is common, these features must be completed sequentially ($F1$ must be successfully completed before starting
+    work on $F2$).
 
     \subsubsection{Pairing}\label{subsubsec:serial-pairing}
 
@@ -182,7 +182,7 @@
             \hline
             Phil  & \cellcolor{blue!10}$F1$ & \cellcolor{blue!10}$F1$ & \cellcolor{blue!10}$F1$ & \cellcolor{blue!10}$F1$ &       & \cellcolor{red!10}Review $F2$ & \cellcolor{blue!10}Rework $F1$ & \cellcolor{red!10}Review $F2$ &     \\
             \hline
-            Gerry & \cellcolor{red!10}$F2$  & \cellcolor{red!10}$F2$  & \cellcolor{red!10}$F2$  & \cellcolor{red!10}$F2$ &       & \cellcolor{blue!10}Review $F1$ & \cellcolor{red!10}Rework $F2$ & \cellcolor{blue!10}Review $F1$ &     \\
+            Gerry & \cellcolor{red!10}$F2$  & \cellcolor{red!10}$F2$  & \cellcolor{red!10}$F2$  & &       & \cellcolor{blue!10}Review $F1$ & \cellcolor{red!10}Rework $F2$ & \cellcolor{blue!10}Review $F1$ &     \\
             \hline
         \end{tabular}
         \caption{A typical day soloing}
@@ -206,7 +206,7 @@
     This includes both the risks associated with non-parallelizable features and the risks of imperfect communication
     and coordination.
 
-    To go fast with soloing with pull-requests you constantly need one stream of work for every developer.
+    To go fast soloing with pull-requests you constantly need one stream of work for every developer.
     Based on the past few decades of building software for startups and enterprise companies, we are unable to name a
     single product that has had absolutely no dependencies between features.
 
@@ -251,7 +251,7 @@
     This occurs when the code is merged into the mainline branch.
 
     \begin{definition}
-        A user story is \textit{finished} once the code is merged into the mainline branch.
+        A user story is \textit{finished} once the code is integrated into the mainline branch.
     \end{definition}
 
     \subsubsection{Pair Programming}\label{subsubsec:pairing}
@@ -266,8 +266,8 @@
         committing to the mainline branch once the code is complete.
     \end{definition}
 
-    As code review happens in real time, the code written for a story is ready to merge into the mainline as soon as it
-    is complete.
+    As code review happens in real time, the code written for a story is ready to integrate into the mainline as soon as
+    it is complete.
 
     \begin{lemma}
         \label{lemma:pair}
@@ -288,7 +288,7 @@
     \begin{definition}
         In the \textit{pull request workflow} each developer works individually and submits the code for each user story
         asynchronous review by others through pull requests.
-        Another developer reviews thoroughly reviews the pull request and suggests changes.
+        Another developer thoroughly reviews the pull request and suggests changes.
         The author reviews these changes, updates the pull request, and merges the code into the mainline branch.
     \end{definition}
 
@@ -313,7 +313,6 @@
         A \textit{backlog} is an ordered collection of user stories.
     \end{definition}
 
-    A backlog is an ordered collection of stories.
     In any non-trivial project there are dependencies between stories that prevent one story from being started until
     another story has been completed.
 
@@ -348,7 +347,7 @@
 
     \begin{lemma}
         \label{lemma:parallel}
-        A team of $2n$ developers with a backlog with more than $2n$ workstreams has an average daily velocity of $4n$,
+        A team of $2n$ developers with a backlog parallelizable into at least $2n$ workstreams has an average daily velocity of $4n$,
         regardless of working model (assuming an 8-hour day).
     \end{lemma}
     \begin{proof}
@@ -360,11 +359,11 @@
     The power of pairing is the ability for a team to work quickly on a backlog, even when parallelization is limited.
 
     \begin{theorem}
-        A well-functioning team of developers working as pairs is as fast or faster than a team of developers using pull
-        requests.
+        A well-functioning team of developers working as pairs is as fast or faster than a team of solo developers using
+        pull requests.
     \end{theorem}
     \begin{proof}
-        Suppose a team of $2n$ developers has a backlog that is parallelizable into $m > 0$ workstreams.
+        Suppose a team of $2n$ developers has a backlog that is parallelizable into $m$ workstreams.
         We will examine three different cases for the size $m$, and show that the team's velocity working in pairs is at
         least as fast as the team's velocity using pull requests.