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.