Here’s an interesting experiment.
Pick an existing Pull Request for a feature that was merged. Give that feature to the PR reviewer and author and asked them to do it again but pair this time.
Count the number of words, sentences or comments they have on that work/code and compare it to the number of words/sentences/comments on the PR.
Would you expect that results you got from pairing are the same as when employing PRs?
Of course not. I expect results for pairing to be multifold higher than PRs.
And that’s where you’re loosing most of your quality. With each and every PR. And I bet you’re chasing that quality afterwards in production which slows you way down.
What if senior developers were not allowed to write a single line of code alone? Everything has to go through the hands of less experienced developers.
Remember the last time you faced a big failure. How difficult was it to acknowledge it and how long did that process take?
As you know, sometimes we can go whole life without being willing or ready to face it.
As the batch size goes up, the emotional investement in it goes up as well, since we’re investing more time in the given solution.
As we become more invested in the solution, the bias towards that solution becomes stronger and it’s less likely for other equal solution to surface.
It’s likely that we become defensive about it as well, just because of the emotional pain of a huge work that we would have to do in case of rework or a complete change of the solution.
Interested in how to implement Drum Buffer Rope from Theory of Constraints to product development teams?
Try out mob programming. It makes sure that the whole team will be running at the pace of its currently slowest skill (constraint), which is essential for:
If you didn’t feel at least a bit of pain when adding new functionality, implementing process or introducing a tool, most probably you already prematurely generalized.
Empiricism assumes some pain because it’s based on learning, not speculation.
