In this weeks episode, I want to introduce the practise of Pair Programming. At first, Pair Programming can seem completely at odds with achieving returns from your software development investment. Though this episode, I will look at the common misconceptions and why this is a valuable practice for ROI.
Or listen at:
Published: Wed, 08 Jan 2020 17:14:38 GMT
Links
The costs and benefits of pair programming
Transcript
Wikipedia describes Pair Programming as:
"Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide."
In summary, it means two people working on the same computer on the same problem.
This works by one person acting as the driver - operating the keyboard and mouse - while the other takes on the role of navigator. They help to direct the driver through the work.
The roles are then swapped on a regular basis.
I can well understand that the thought of "two people working on the same thing at the same computer" may cause concern - and lead you to question of "why would I pay two people to do the work of one?"
And I've seen this question in practice.
A project manager will open question the logic behind having two people working on the same thing together. "Surely we will get more done if they work on their own work? It a more efficient use of people".
I'll come back to the economic question in a moment, but first let's talk about the idea of effective use.
Douglas McGregor created two theories for work motivation and management in the 1950s - theory X and theory Y.
Theory X is based on the assumption that a typical worker has little ambition, avoids responsibility and is individual-goal oriented. The management assumption is that those workers are less intelligent, lazier and work solely for a sustainable income. Largely these works will be motivated through punishment and rewards.
Theory Y is based on the assumption that a typical worker is internally motivated, enjoys their job and work to better themselves without a direct reward in return. The management assumption is that these are the most valuable assets to the company, pushing the organisation forwards.
We managers and leaders will all have a natural bias to theory X or theory Y - this will generally colour our approach to many situations.
So if our natural bias is to theory X, we will likely be more comfortable using a command and control style of management, building several layers of supervision and management, and favouring micro management.
Whereas, if we are more naturally biased to theory Y, we are more likely to have a "hands-off" management style.
Different situations favour the use of theory X thinking over theory Y - and vice-versa. And while there is not a single "best way", I would however strongly advocate for theory Y thinking when it comes to any form of knowledge work.
And especially development.
If we look at Pair Programming through theory X; then yes we will be thinking about resource utilisation - "is the second person slacking off?", "are we getting poor return on investment?".
If we look at Pair Programming through theory Y; we start to think about it more in terms of the value delivered.
I unashamedly have a theory Y bias; but I will look to cover both perspectives in this episode.
So lets start with the economic concerns;
To set expectations; when we look at the developer-hours spent, I would be prepared to concede that it costs more to pair program.
You may however assume that because there are two people working on the same problem, then you are experiencing an increase of 100% on the developer-hours.
Research from the 2001 paper "The costs and benefits of pair programming" by Alistair Cockburn & Laurie Williams calculate this will be closer to 15%.
They also found that the benefits achieved greatly outweighed that additional cost.
A quote from papers abstract:
"Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels."
I'll provide a link to the paper in the show notes.
The act of pair Programming in far from new.
It was documented as one of a number of practices under the title of Extreme Programming. It was documented in a book called "Extreme Programming Explained" in 1999. Extreme Programming was intended to improve software quality and responsiveness to changing customer requirements.
Many of the Extreme Programming practices has been adopted by both the Agile and DevOps movements.
We'd already covered some practices in this podcast series that have their origins within Extreme Programming - practices such as Continuous Integration, small releases and automated testing.
And while pair programming is probably not as widely adopted or understood as some of those other practices, it is generally accepted as net beneficial for software development by most thought leaders in the industry
So from a purely economic view;
I believe the case can be made that the benefit of receiving the change earlier is enough to justify the additional cost.
I will always advocate speed of delivery because that allows us to deliver value to our customer faster. For me, this always trumps perceived utilisation of an individual - part of the theory Y bias.
But, as per the abstract from the "The costs and benefits of pair programming" study, there are additional benefits that pair programming bring to the ROI calculation.
Having two sets of eyes on the change leads to better quality. I've talked about how better quality earlier has a massive affect on the total cost of ownership.
If a problem can be highlighted and fixed by the developer at source, it can be hundreds of times cheaper to resolve than if it makes its way into the hands of your customer.
"The costs and benefits of pair programming" study found that, through pair programming, there was a statistically significant difference in the defects found - with the pair programming giving approximately 15% less defects.
As I've commented before; software defects are inevitable. Software Development is the act of a human - and thus mistakes are not only likely, they are to be expected.
Thus any activity that can highlight that defect earlier is great for reducing the overall cost of any given defect.
Problem solving becomes a lot more fluid with two people.
Having two people helps to reduce time where a developer is "spinning their wheels" - struggling to find a solution to a problem.
Again its a factor of human nature that occasionally we get stuck on a problem - ask any author about writers block.
In these circumstances, two heads are definitely better than one.
Where one person may become stuck - the simple act of having two people to talk the problem through is often more than enough to define a path forwards.
You also find that have those two minds creates a better path forwards.
Often there is no single correct answer in software development. More commonly there are a number of answers with different trade offs.
By having two minds, while it is still very possible (and expected) to go down the wrong road, it is less common.
Again, this is actually saving time and effort in the full lifetime of the software product.
Pair programming is also often cited as an effective means of training and team building.
By working together so closely, a natural side effect is both the sharing of knowledge and familiarity.
This helps to make the team stronger in the face of adversity and more resilient to the loss of key individuals.
Again these are benefits backed up by the "The costs and benefits of pair programming" study.
While hopefully, I've covered off a good number economic and benefit concerns, there are still things to watch for in the use of Pair Programming.
First is a culture problem; not all developers will be receptive to it. They may prefer to work alone; they maybe very much a natural introvert. There could be a number of reasons behind a reluctance to engage with Pair Programming; anything from a fear of being that intimate with another developer to simply feeling hamstrung by another developer.
These are valid concerns ... But not a reason to not introduce the practice of Pair Programming. While not all developers will convert to loving Pair Programming, giving them the option to explore it will likely cause a natural migration on its own.
The key here is not to force it. Rather, make it understand that it is not only allowed, but that its practice is encouraged as good practice.
The other problem is perceived freeloaders;
And even with my theory Y bias, I have to acknowledge that there are people that will quite merrily let their partner pick up all the work while they surf the internet.
Where I deviate from my theory X colleagues is that, I don't see that as being a big enough of a concern to give up the benefits that Pair Programming can bring.
I know that a team will quickly highlight a freeloader on their own. It will become very clear very quickly if there is someone that really isn't pulling their weight.
And quite often the team themselves will address this directly with the individual.
More often that not, the problem simply goes away as part of the improved team communication.
In this episode, I've introduced the practice of Pair Programming - where two people work on the same problem at the same computer.
Referencing "The costs and benefits of pair programming" study throughout, I've:
Addresses the economic concern of increased developer-hours.
The benefits of fast delivery, better quality, knowledge sharing and better team communications.
And I've also provided advice on how to handle those developers not-keen to use the practice and perceived free loaders.