[pinaceae]

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?

[benohear]

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.

[mattcofer]

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.

[rickmb]

Q&A doesn't fix any problems, it merely identifies them before they go into production.

If a significant amount of time is spend on fixing bugs, the problem is elsewhere in the process. Solving that problem should be the highest priority, because that's were things will continue to escalate.

[mattcofer]

I agree. A lot of bugs could indicate one of two things. First you need to differentiate between bugs caused by developer error and bugs caused by lack of project planning/scope. For example, a bug report that complains 'columns in the grid do not support sorting' is not a bug. They are feature requests not originally defined in the scope of the project. Bugs such as one where 1+1=3 due to a developer's bad algorithm are actual bugs. There is a big difference here. These are the bugs that should be caught by QA long before the release and while the project and algorithm are still fresh on the developers mind. There needs to be accountability for lack of planning or assuming that every time a developer uses a widget that it will have every feature possible for that widget to have.