3 ms·

I generally find that more resources are often the easiest thing to get and rarely helpful. Most of the time the issue is the "9 women can't have a baby in a m

I generally find that more resources are often the easiest thing to get and rarely helpful. Most of the time the issue is the "9 women can't have a baby in a month" problem where adding more resources is not going to make things happen faster - in fact it may slow things down. But the business doesn't understand that software is not like construction where adding more people really will get that ditch dug faster. At its core software is not making a thing - it's inventing a machine that makes the thing. If you're Little Debbie and you have a machine that makes cupcakes it's hard when the business comes in and says, "now it needs to make fudge rounds." And no amount of extra people working on the problem will get that machine retooled any faster.

bluefirebrand 2y ago
> But the business doesn't understand that software is not like construction where adding more people really will get that ditch dug faster. People tend to understand that there's an upper limit to the amount of people that can be deployed to dig a ditch any faster too They just refuse to believe that with software, sometimes that number is smaller than they think it should be simply because people aren't physically getting in each others way
ska 2y ago
Oh, I wasn't meaning to suggest that all problems are solvable by throwing more resources at it, that clearly isn't the case. But it's super common for a team to be asked to do something fundamentally outside their scope, and the asking client/boss not realizing that they are doin g it. "Figure it out" as a useful strategy sort of assumes that both sides of the equation are clued in about this and roughly on the same page. "I underwrote a great team, you should be able to figure this out (stop whining about it being hard)" is a fundamentally different statement than "Why can't you just do X, how hard can it be?" It's also worth remembering that the plural of "resource" is not "team".

bluefirebrand 2y ago

> But the business doesn't understand that software is not like construction where adding more people really will get that ditch dug faster. People tend to understand that there's an upper limit to the amount of people that can be deployed to dig a ditch any faster too They just refuse to believe that with software, sometimes that number is smaller than they think it should be simply because people aren't physically getting in each others way

ska 2y ago

Oh, I wasn't meaning to suggest that all problems are solvable by throwing more resources at it, that clearly isn't the case. But it's super common for a team to be asked to do something fundamentally outside their scope, and the asking client/boss not realizing that they are doin g it. "Figure it out" as a useful strategy sort of assumes that both sides of the equation are clued in about this and roughly on the same page. "I underwrote a great team, you should be able to figure this out (stop whining about it being hard)" is a fundamentally different statement than "Why can't you just do X, how hard can it be?" It's also worth remembering that the plural of "resource" is not "team".