Pull Request workflow just cannot be compared to Pair Programming

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.

»
Author's profile picture Dragan Stepanović

What if senior developers were not allowed to write a single line of code?

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.

»
Author's profile picture Dragan Stepanović

If I have to raise a PR to rename a method that bothers me, I’d rather not do it

And this is a short story about the process that penalizes people for trying to do their best.

»
Author's profile picture Dragan Stepanović

When batch size goes down, confidence goes up

Interestingly, I noticed that the smaller the steps I take when refactoring, the less of a need I have to run the tests.

»
Author's profile picture Dragan Stepanović

Big batches tend to make failures less than they actually are

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.

»
Author's profile picture Dragan Stepanović

Move the work to the people, not the people to the work

»
Author's profile picture Dragan Stepanović

Big batches incentivize for choosing a suboptimal solution

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.

»
Author's profile picture Dragan Stepanović

Mob Programming is a Drum Buffer Rope implementation

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:

»
Author's profile picture Dragan Stepanović

Queue time has way more leverage than processing time

Lead time = processing time + queue (feedback) time

»
Author's profile picture Dragan Stepanović

Sign of a premature generalization is lack of pain when trying to progress

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.

»
Author's profile picture Dragan Stepanović