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.

Re:Management

[Cederic]

Harshly put, and only partly right. Project managers manage resources, budgets, costs, stakeholders, timescales and as a result, the project.

The architect also manages the project, but takes accountability for the technical correctness of it, the design, the quality.

In other words, the answer is to get a good architect. Make them accountable for quality. Give them the authority to deliver on that accountability.

At this point the number of bugs becomes irrelevant, the complex compromises between functionality, security, user experience, data integrity, resilience, stability, availability and cost can be properly assessed.

Bugs are a tiny part of the whole.

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.

Re:Obvious, really

[NoNonAlphaCharsHere]

You're skipping the part where the project was understaffed in the first place, requirements were ill-defined and ever-changing, and the final arbitrary, unrealistic, pie-in-the-sky delivery deadline date (the ONLY immutable thing in the whole goddam project) was pulled out of someone's ass. Oh. And the devs got pulled away on occasion to fix hair-on-fire bugs in projects they worked on previously (or even better: had no experience with).

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.

Well known problem; well known solution

[Hairy1]

This is of course a well known problem documented in the paper Big Ball of Mud by Brian Foote:http://www.laputan.org/mud/. The basic problem is that many systems grow organically as new features are required, but as new features are added to the system it becomes more complex and tightly coupled. Another aspect I have noticed might be the 'Black Hole' syndrome. In systems that are custom written and business critical there is no clear scope of the project. With no clear scope anything new that the business needs is simply thrown into the existing system. The never ending scope creep means that the system takes more and more responsibility. And so grows a monolithic tightly coupled black hole. Because it is at the centre it tends to attract any new requirements because anything new needs to interact with it. And the more you add the harder it is and the more bugs you introduce.

There are well known solutions of course. The first would be to read the link above. However, there are two broad areas to address, and you need business buy in for both. The first is software development discipline; proper code repositories, regular check in, unit tests, code reviews. And while there should be nothing new here there is often resistance from management. You need to explain to management that poor quality means lower development velocity. Taking time to do testing and code reviews may appear to take time, but try not doing it and you find out pretty quickly the folly of ignoring quality. This is just basic coding hygiene. You can of course also apply agile principles and practises, such as time boxing of iterations and regular feedback from users.

But okay, you have an existing system you need to fix. Service Oriented Architecture is more than just a buzzword; it is the principle of separation of concerns. First thing to do is define what the system does. Does it do multiple things? You need to have a clear idea about what the system does, and to then begin to cleave them into separate systems with clearly defines scopes. Sometimes this means identifying relatively simple subsystems to separate. Break the system apart and introduce well defined contracts.

Refactoring code without getting a eagles eye view of the whole system and where to introduce the interfaces is dangerous. Often this process of architectural clarification can cause systems to experience complexity collapse as duplicate code is reduced and removed. Premature re-factoring at the class level may introduce little benefit. Better to pull off the small subsystems with a clear scope and purpose and ensure the code in these new subsystems do not include unnecessary external domain objects.

Again, without having the business behind you a project like this is doomed. You need to present a clear plan to the business and explain how it will improve quality and the ability to add new features, while reducing development costs. You need to explain that this is not a issue with the quality of software developers, but rather a systemic problem that can be corrected. And of course for this you need someone with the courage to tell this story in a compelling way.

Got it good

[JBMcB]

Thanks for these headlines - reminds me of how good I got it. My manager is a former developer. I have, maybe, two or three hours of meetings a week. The issue list is planned out every Monday - if something high priority comes in, something gets taken off the list. If anyone starts monopolizing my time he fends them off or clears the schedule.

I have an acquaintance who went to work for a huge web company (not that one, the other one.) He's a pretty experienced developer, so he grilled them on their development process during the job interview. All the right things were said. They were all lies. He quit after two weeks.

Here's what should happen but doesn't

[the_Bionic_lemming]

I was handed a problem where SQL couldn't handle the parameters in code from a product that wrote code in a convoluted way. It took me two weeks to handle it, but the fix I eventually pushed out made sure that the issue would never happen again.

Despite the fix working for about ten years now, I never got an apology for being punished over the fix taking more than the nitwit manager saying it would take to fix.

If you want code teams to fix stuff right, make sure that the code guy is a manager. If you want someone to blow smoke up your ass and punish people that fix things promote suckup people that have no idea on how to code, or hire h1b's.