←back to thread

268 points behnamoh | 1 comments | | HN request time: 0.203s | source
Show context
capableweb ◴[] No.28668272[source]
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.
replies(4): >>28668376 #>>28668394 #>>28668452 #>>28688773 #
notimetorelax ◴[] No.28668376[source]
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.
replies(1): >>28668475 #
1. TeMPOraL ◴[] No.28668475[source]
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.