The Sad Graph of Software Death (tinyletter.com)

An anonymous reader writes: Programmers, raise your hand if you've been on a project where bugs keep piling up, management doesn't dedicate time to fix them, and the whole thing eventually bogs down. Gregory Brown summarizes that situation in one simple little graph from an issue tracker, and discusses why so many companies have problems with it. "This figure tells a story that is no way surprising to anyone who has worked on software projects before: demand for fixes and features is rapidly outpacing the supply of development time invested, and so the issue tracker is no longer serving as any sort of meaningful project planning tool. In all but the most well-funded, high functioning, and sustainable businesses — you can expect some degree of tension along these lines. The business side of the house may blame developers for not moving fast enough, while the developers blame the business for piling work on too quickly and not leaving time for cleanup, testing, and long-term investments. Typically, both sides have valid concerns, but they don't do an especially good job of communicating with one another." What methods have helped you deal with situations like this? What methods haven't helped?

Comments

Management

[Lisias]

Communication is the main task (and, IMHO, should be the sole one) of managers.

Get rid of that wave of mongols that call themselves "Managers", give the task to someone that can understand both sides, and you will see things going better.

Re:Management

[Anonymous Coward]

My problem is this one

'drop whatever you are doing this is your top priority' then 'why is xyz not done yet'.

I spend at least 2-3 days a week in meetings. The remaining time is spent doing 'support'. The other time is supposed to be my development time. Guess which one suffers?

My 'passion' is gone. I come in at 9ish leave at 5. I then take a decent lunch. I dont care anymore. They do not want to let me schedule time for dev work. I am not going to give them extra time. They dont care then I dont.

Re:Management

[sunderland56]

No, I think that being an effective *filter* is the main task of a manager. Communicate and prioritize the requirements from above that make sense; but block ones that are stupid or not worth it. Communicate the needs of the team up to management (again, ones that make sense) and make sure they get addressed. And, most of all, block the constant stream of questions and requests from sales/marketing/support, and force them to all pass through you. That way you (a) will soon recognize who brings reasonable requests, and who does not; (b) get to know which areas of the product get the most questions, and so may need work; and (c) allow your team to work mostly uninterrupted.

You're right that under-communication is an evil sin; but so is over-communication.

Re:Management

[Opportunist]

I think that's not what he meant. What he meant is the management equivalent of the sales person who claims that it doesn't matter whether he's supposed to sell mattresses, cars or refrigerators.

A manager has to know at the very least (AT LEAST!) the pitfalls of what he is managing. Of course not the technical side, but the management side. In IT this means that he has to know that bugs WILL happen and that he WILL have to dedicate time to fixing them, that wishing them away will not work and that customers will want them fixed because they notice them and you can only bullshit them so long into "it's a problem on your end".

Re:Management

[Anonymous Coward]

I have thought about having T-shirts printed up that say "The meetings will end when morale improves". There is nothing like an excessive number of meetings that sucks the life out of me. Fortunately I don't work on that product any more.

Idiots

[penguinoid]

The business side of the house may blame developers for not moving fast enough,

Yes, but that is the most pathetic excuse ever. No one is preventing the business from hiring additional workers, if the business lied about its workers' capabilities or is managed by idiots who substitute optimism for basic estimation skills that's their own problem.

The other side of the coin

[Jeremi]

... is, if you're still receiving bug reports and feature requests, that means people are still interested in using your software.

You know a particular program is really dead when you stop receiving feedback from users about it -- that means either it is finally perfect and bug-free (ha ha, not bloody likely), or everybody has given up on it and moved on to something else.

Start by categorising bugs

[mikael]

Figure out what those bugs are coming from. Are they documentation, failed unit tests, new features, badly colored GUI widgets, or more hardware features?
It isn't going to help to have a recruitment blitz for more hardware engineers if your technical writers can't keep up with the documentation.

at least partly a project management problem

[david_bonn]

Like the article said, this could well be a symptom of poor or clueless project management. Duplicate issue reports and low-priority nice-to-have items may be overwhelming actual problems. On the other hand, this could also be a case of software "maturity" where it becomes difficult, if not impossible, to fix any bugs without introducing new ones.

The least bad "solution", as a technical lead or developer, is to abandon the problem tracking system. To politically sell this idea it describe it as a "critical bug tracking system" and make it a simple command-line or email interface that only the lowly code grunts and technical leads will be comfortable with.

Another "solution" is to start closing problems and declaring they cannot be fixed without a redesign of the product.

One thing to remember is that substituting product management with a bug tracking system is seriously lame. We all use software, from web browsers to compilers to editors to source control systems to databases, that has bugs. Each new release of said software will fix some bugs and introduce new ones. Most of the time, for most users, if we had a choice between fixing those bugs and making the product in question ten times as fast or use 10% the memory we'd take one of the latter over the bug fixes. What I'm trying to communicate is that an "issue tracking" system can't usually communicate what customers want or need perfectly.

Figure Out What Happened on April 7th

[dcollins]

Looking at the graph in the article, there's on obvious inflection point that occurs on 7-Apr. Prior to that, the two lines (opened and closed items) are basically tracking each other. After that point, the opened items (red) retains the same slope; but the closed items (green) switches to a different, shallower (but thereafter basically constant) slope. And thus the two curves veer away from each other from that point.

So: What happened on 7-Apr? Did one or more developers quit, burnout, take a long vacation? Maybe they haven't been replaced yet?

After that I'd try real hard to stop new features from coming in, and start thumbing through a Brooks book to look for suggestions in an emergency like this.

Re:agreed dev time is the last to get allocated

[Z00L00K]

If management were to add bugs into the bug tracker then you would have complete chaos - most managers don't know crap about what the bug reports are about and can't distinguish a bug from an enhancement. Let it be the responsibility of the developer to re-classify bugs that should be enhancements and submit such to a decision board for future enhancements.