←back to thread

Always Multiply Your Estimates by π (2013)

(web.archive.org)
268 points behnamoh | 4 comments | 27 Sep 21 04:48 UTC | HN request time: 1.197s | source
Show context
capableweb ◴[27 Sep 21 08:11 UTC] 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 #
1. Aeolun ◴[27 Sep 21 08:33 UTC] No.28668394[source]▶
Wait, so you are saying that the net positive effect of adding an extra engineer is zero?
replies(3): >>28668455 #>>28668719 #>>28669416 #
2. capableweb ◴[27 Sep 21 08:42 UTC] No.28668455[source]▶
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.
3. wruza ◴[27 Sep 21 09:28 UTC] No.28668719[source]▶
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.
4. hemric ◴[27 Sep 21 11:29 UTC] No.28669416[source]▶
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.