I agree with the idea in general, but not with its implementations I see.
If making things reliably on time is so important, you could simply hire more people. (Not in the last minute when you already see that you will miss the deadline; by then it’s usually too late.)
In my experience, many software projects are late because the teams are chronically understaffed. If you are completing deadlines reliably on time, the managers feel that you have too many people on your team, so they remove one or two. (Maybe in other countries this works differently, I don’t know.) Then there is no slack, which means that things like refactoring almost never happen, and when something unexpected happens, either the deadline is missed, or at least everyone is under big stress.
The usual response to this is that hiring more people costs more money. Yes, obviously. But the alternative, sacrificing lots of productivity to achieve greater reliability, also costs money.
Now that I think about it, maybe this is about different levels of management having different incentives. Like, maybe the upper management makes the strategical decision to sacrifice productivity for predictability, but then the lower management threatens predictability by keeping the teams too small and barely meeting the deadlines, because that is what their bonuses come from? I am just guessing here.
In my experience, many software projects are late because the teams are chronically understaffed. If you are completing deadlines reliably on time, the managers feel that you have too many people on your team, so they remove one or two.
It’s interesting that you say that, because my experience (US, large corporation IT—think large banks, large retail, 100,000+ total employees) has been the exact opposite. The projects that I’ve been working on have been all quite overstaffed, resulting in poor software architecture, thanks to Conway’s Law. When I worked at the major retailer, for example, I genuinely felt that their IT systems would be healthier and projects would delivered more quickly if they simply fired half the programmers and let the other half get on with writing code rather than Slack messages.
I agree with the idea in general, but not with its implementations I see.
If making things reliably on time is so important, you could simply hire more people. (Not in the last minute when you already see that you will miss the deadline; by then it’s usually too late.)
In my experience, many software projects are late because the teams are chronically understaffed. If you are completing deadlines reliably on time, the managers feel that you have too many people on your team, so they remove one or two. (Maybe in other countries this works differently, I don’t know.) Then there is no slack, which means that things like refactoring almost never happen, and when something unexpected happens, either the deadline is missed, or at least everyone is under big stress.
The usual response to this is that hiring more people costs more money. Yes, obviously. But the alternative, sacrificing lots of productivity to achieve greater reliability, also costs money.
Now that I think about it, maybe this is about different levels of management having different incentives. Like, maybe the upper management makes the strategical decision to sacrifice productivity for predictability, but then the lower management threatens predictability by keeping the teams too small and barely meeting the deadlines, because that is what their bonuses come from? I am just guessing here.
It’s interesting that you say that, because my experience (US, large corporation IT—think large banks, large retail, 100,000+ total employees) has been the exact opposite. The projects that I’ve been working on have been all quite overstaffed, resulting in poor software architecture, thanks to Conway’s Law. When I worked at the major retailer, for example, I genuinely felt that their IT systems would be healthier and projects would delivered more quickly if they simply fired half the programmers and let the other half get on with writing code rather than Slack messages.