The 80:20 rule (Pareto principle) fits into this as well. You can make easy inroads into each individual project if things are divided up - getting any of them to a viable state however starts to bog down.
Productivity isn't linear. Especially when you mix in Tuckman's group dynamics.
Sorry but I disagree. The best engineers are the ones that can plan reliable estimates and hit their targets. They deserve to be highly paid, since they create stability and predictability in an otherwise chaotic process. You don't have to be a speedy coder in order to be highly valued. You just need to be reliable, and the team needs to have confidence in the work that you do.
To do things like cut the number of features in half and double time estimates, as is advocated by the author, are things that only contribute to red tape and chaos.
So, would you rather have someone who can hit their targets all the time, or someone who often misses but is done in half the time? For anything non-trivial, and non-boilerplate things get complicated. People pad their estimates and work towards that deadline.
Half the time with same amount of bugs? I consider low bug-count as part of the requirement for "predictability", since a buggy product isn't considered finished.
If you're talking about someone who consistently hits their deadlines with a low bug count, vs someone who gets it done in 1/3 of the time, but 1.5x as many bugs, I would prefer the person with the longer but more predictable times.
As well, if the entire team is targeting 6 weeks, and the unpredictable person finishes their task in 3 weeks, then it means that the entire schedule gets out of joint. I would prefer the person had better insight into the task and say it would take 3-4 weeks, so that other work could be properly scheduled.
6 comments
[ 4.6 ms ] story [ 21.0 ms ] threadProductivity isn't linear. Especially when you mix in Tuckman's group dynamics.
Same old topic that has been discussed over and over before.
To do things like cut the number of features in half and double time estimates, as is advocated by the author, are things that only contribute to red tape and chaos.
If you're talking about someone who consistently hits their deadlines with a low bug count, vs someone who gets it done in 1/3 of the time, but 1.5x as many bugs, I would prefer the person with the longer but more predictable times.
As well, if the entire team is targeting 6 weeks, and the unpredictable person finishes their task in 3 weeks, then it means that the entire schedule gets out of joint. I would prefer the person had better insight into the task and say it would take 3-4 weeks, so that other work could be properly scheduled.