Why You Shouldn't Hire More Developers

This is very interesting, however there seems to be a bit of magic going on.

It is observed that the time fixing bugs can be used in a more productive way. But those bugs still needs fixing.

Quote: "If your team is spending time any significant amount of time fixing bugs, it has much more capacity than you realise. That’s not to say it’s an easy reserve to tap into, but it is there."

Ok, I agree. So how exactly do you tap into that resource. I am currently facing exactly the scenario described in the article - a successful sales team shoving new stuff into the pipeline, an evergrowing backlog of things to fix and do (bugs, architecture, clean-up).

Our solution so far consists of:

1., We serve multiple platforms. As Blackberry, iPhone, Windows Tablet are pretty much dead against iPad, we're shifting those developers over to iPad. New technology, but at least same business processes.

2., Hiring a few more devs.

If I understand the article correctly, the investment should go into more Q&A, finding bugs asap to get out of the long tail of production fixes.

What's the HN community' take on this?

That annoyed me too. I can see the point of decreasing the bugs introduced (eg by working less hours and better testing methods), but at some point your team will be at full capacity so you will need to expand. It seems that the only solution is to do so far enough in advance so the new hire has time to be broken in before the extra productivity becomes necessary.

One thought is to look at what can be reasonably offloaded to a new person. For example I recently had to step in and sort out the HTML for a project for which we did design and where the developers were struggling and overwhelmed. Not having to worry about how things looked anymore was a big burden off their shoulders, and it's a well enough contained area that I could be productive pretty much instantly.

You make more money and grow your business by developing new features, not by fixing bugs. Some bugs must be fixed now and that is fine but if you spend a lot of time trying to fix every bug then you never develop new features. I think that is the point that was trying to be made.

This the culture we are trying to change at work. Shift from a drop-everything-and-fix-the-bug-now culture to a fix only true emergency bugs now and mainly focus on developing new, high impact features. In other words, expanding the business capabilities of the software. Note: This will bring in more profit and grow the business which eventually will lead to hiring of more developers to handle new projects.

Excellent read, but unfortunately a little lacking in terms of solutions.

I've found myself in this position a few times, and in general, it was more likely to happen in Sales-focused organizations where non-technical sales people were all too eager to make unsustainable promises to land big customers for lots of cash.

Often the customers' real business problems could have been handled more elegantly with minimal code churn and a more sustainable pace for the dev team. But without a solid Product Manager to guide them to the right solution, an incoming request from sales was more likely to just be reformatted and then turned into a user story and/or bug.

I always felt the only sensible solution was to re-align the business expectations and help the product find it's focus, but frankly I was never successful at pulling this off.

As brador observes, the problem isn't the hiring, it's that the hiring came too late. The solution is that you have to suck it up and hire Alice anyhow, and probably one or two others. Yes, in the short term they'll make things worse, but in the long term you'll be able to recover. The alternative is that in the short term things stay bad and in the long term things get worse.