[nhashem]

Why You Should Hire More Developers: Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth.

Let's assume this company has nobody with a true technology background at its leadership level, because if it did it you wouldn't have this mess to begin with. That means it's basically never an option to say, "can we stop working on business projects for two weeks so we can fix problems with our infrastructure that will make us more efficient later on."

Suggesting something like that never works because:

-- The idea of halting "forward progress" on "revenue-driving initiatives" is anathema to any executive. I've once worked on projects where the conversation with my manager has gone like this:

"[Executive] wants us to make progress on the SuperProfitGenerator Widget this week."

"On top of everything else? That's a HUGE project! How could we finish it this week?"

"She doesn't want it to b finished, she just wants forward progress."

"What's the definition of forward progress?"

"Well she just wants to know we're working on it and we're closer to finish than we were at the beginning."

"But I'm not supposed to have anything functional or anything, just 'forward progress.'"

"Yes."

"By what metrics? Lines of code? If I tell her I wrote 10,000 lines of code for the SuperProfitGenerator Widget, that will make her happy?"

"Yes."

"Wow. Okay. Um, yeah, we can squeeze that in."

[proceeds to create SuperProfitGenerator.pm class and copy-paste 10000 lines of Wikipedia into it wrapped in a "print" statement]

-- It's incredibly hard to quantify the actual efficiency gains and business people basically just assume engineers are lying anyway. Unfortunately I've seen this sort of Catch-22 play out -- it seems like the business will relent, but they want to try and quantify the efficient gains. The engineers give incredibly optimistic answers because a) we're typically terrible at estimating to begin with b) the rosier we can paint the picture, the more likely they'll finally buy-in. Unfortunately then it's very hard to deliver on those efficiency gains, and even if you do deliver, it's hard to make non-engineers realize the impact. Everyone realizes when an extra $50,000 is in the bank account. Not everyone realizes that 5 engineers have each saved 10 hours, even though an extra 50 hours of productivity over a year is easily worth more than $50,000.

-- Even if they do agree to let engineers start working on systemic/infrastructure problems, it's typically the first thing that gets prioritized. Some client will come in talking about some deal that could be worth some non-zero amount of dollars but requires additonal engineering work. The executives sit around looking at the current priorities and someone says, "It looks like the top priority right now is 'Data Model Refactor,' whatever the fuck that is. What the fuck is that? Oh it's something about database the engineers wanted to do? Fuck that, make them work on this instead."

So what can you do? If you have the option of fighting to get technical debt and infrastructure issues addressed, or just hiring more, than in an envirnoment like this it's almost always the better move to hire more. Hiring someone for a later project does make it later, but the OP is talking about a systemic overall inefficiency. It's very possible the new hire will come in and gum up the works for awhile during his ramping up phase, but on a long enough timeline they will eventually out-produce the overhead. It's politically easier to bring on someone new, deal with the productivity hit, and then have them start addressing the systemic technical issues.

Although the real answer to "what can you do?" is to not work at these kinds of companies to begin with. Companies with leadership that has true technology backgrounds don't allow these kinds of situations to arise to begin with, and if they do it's very easy for them to understand the cost-benefit analysis of dealing with them. This isn't the case at your typical organization led by a bunch of MBA idiots, unfortunately.

[dustingetz]

> can we stop working on business projects for two weeks so we can fix problems with our infrastructure that will make us more efficient later on

this attitude is contributing to the problem; it takes continuous and disciplined investment in quality. the idea is that slowing everything down (forever) by a linear factor of two or three will cause exponential returns in productivity later.

[rpwilcox]

> Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth.

Yes and no. Politics and systemic issues are hard to face up to, but sometimes they make the problem worse, so they really do need to be fixed to make the problem any better.

Say you have everyone working 70 hours a week, and someone thinks to throw more people at the problem. You start interviewing.

2 weeks later, Bob quits in a fit of rage. (Or maybe hospitalized for exhaustion and quits. Whatever.). Now you're down an engineer, and you have to find two more engineers, making the HR department work even harder.

3 weeks later you find _one_ developer. You can't seem to find another - between good talent being hard to find, and people suddenly getting cold feet after doing face to face interviews with your blurry-eyed engineers... well there's a talent crunch going on after all, don't ya know? ;-)

And you're now 6 man weeks behind (and no closer to your goal of another engineer).

Boy, this new guy better hit the ground running, because you really need the help...

[rwos]

> It's politically easier to bring on someone new, deal with the productivity hit, and then have them start addressing the systemic technical issues.

I can see the reasoning behind that and it would be wonderful if that tactic actually worked. In my experience however, it does not.

I work at a company that is heavily driven by a non-technical management. They don't understand the concept of "technical debt" and your characterization of how it is to work at such a company is _exactly_ like I have experienced it. But: the managers/MBAs/what-have-you at my company are not idiots. The problem is: if they bring in a new hire into a team (which happens fairly often, we went from ~100 engineers to more than 250 in 2011 alone), they also raise their expectations of said team's output.

The team-leads (which is the highest technical position in my company) do, of course, try to fight that back and try to use the plus in productivity for fixing underlying technical problems (of which there are plenty). Sadly, they have a hard time explaining even the productivity drop that stems from bringing the new team member up to steam. After that, there is just not enough argumentative leverage (I hope that's a term that exists) left to explain why we could not move even faster, now that we are one engineer more.

So, in the end we are exactly where we were - and find ourselves longing for another new hire to work exclusively on the technical debts.

[kvnn]

> Let's assume this company has nobody with a true technology background at its leadership level, because if it did it you wouldn't have this mess to begin with.

From immediate experience, this is false.