Always Multiply Your Estimates by π (2013)

This is good advice but forgets that people are part of how long time something will take as well. If it's one engineer, it'll probably take $estimation * π, but if it's two engineers, you probably need to double that. If it's three, triple it. New calculation should be something like "($estimation * π) * $peopleWorkingOnSameThing". Communication overhead and mistakes should not be underestimated.

I agree that communication overhead exists but I think you’re ignoring the benefit from having 2 people working through a problem vs one person. I’ve seen much faster results because people don’t tend less to get stuck if pairing with someone.

Wait, so you are saying that the net positive effect of adding an extra engineer is zero?

Yes, more engineers working on the same problem = slower time to actually releasing anything. Unless you can find a way to divide the task into parts that don't impede the others, adding more people will make things take longer time.

In my experience, that's pretty high-variance. The perfect result - one where you get anywhere from 1.5x to 10x boost of productivity - requires pairing people who communicate well, are on relatively similar skill level[0], can focus, and who both have a good day. No distracting personal issues, no emotional problems, or other kinds of things that make you unable to focus in presence of other people. If any of those conditions isn't met, pairing up will waste time.

There's some confounding involved, of course - for example, a good rapport with teammates can mitigate the effects of private issues. But my point is that you can't just pair people up and expect productivity to improve; it'll likely decrease, and it'll likely swing wildly from day to day.

--

[0] - With respect to division of work on the task. Like e.g. a long time ago I was in a gamedev competition with a team of artists. I was nowhere near as good a programmer as they were artists, but we decided to make an art-heavy game, so our workloads balanced out and we proceeded almost in lock step.

It is usually net negative until 5-7 people and a leader who can think over everything and write/schedule/dispatch crystal-clear requirements. Teams of identical skills only reduce (or increase, depending on the definition) bus factors and smooth out refocusing time and stress, but they don’t add real productivity. Software development is a tetronimo game which turns into pentonimo and so on with extra members added.

In my experience it may most of the time take longer time to have stuff done BUT what is implemented will be better engineered and robuster. As long as you do some pair-programming and pair code review from time to time, the fact that you must develop a system that is understandable by more people leads to a better architecture.

Don't forget politics. Depending on the team, rework can be demanded by some alpha male positioning for power, just so he can assert his dominance.