A few years ago, I helped save a company by showing them a single picture that took almost no work to produce.

Although formally speaking, the picture was titled Issue Open vs. Close Rate Over a Four Month Period — I tend to refer to it as The Sad Graph of Death when discussing it in educational conversations. Here it is, in all its glory:

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.

When this problem becomes severe enough or persists long enough, you end up with the sad graph of death shown above. And what the graph tells us is that both backlog length and issue resolution time are trending towards infinity. Even if the team is able to respond some small number of issues quickly, the fact remains that most will take a very long time to be resolved if they get worked on at all, and that situation will get worse over time unless something changes.

In the best case scenario, an open/close graph that looks like the one I’ve shown in this email is more of a sign of messy project management practices than it is of imminent doom. There might be lots of old tickets that were actually fixed but never closed, or a ton of duplicate issues that are artificially inflating the total count. Or in the “packrat project manager” scenario, there may be tons of low priority nice-to-have tickets that have been sitting around for months or years, even though everyone knows they’ll never be worked on any time soon. If this is the case, the graph is still “sad”, but it’s not a death spiral… it’s just a sign of a wasteful and broken issue tracking process.

However, in my case, I built this graph because the company I was helping was going through major struggles. If you look around and everything is on fire and your application seems to be about to collapse into the sea AND you produce a graph like this from your tracker, it’s a sign of a real problem that needs to be dealt with right away.

What would you do in this situation? Take a minute to think about it now.

If your first instinct is to present this information to a project manager and then call for more time for testing, cleaner code, and improved architecture… your heart is in the right place, but you’re putting the cart before the horse.

And if you’re thinking “after this iteration, we’ll request a couple weeks off for cleanup and working through the backlog of issues” — that’s a brilliant idea, but it sounds a bit like wishful thinking if you’re currently part of an organization that has let things degrade to this point. There may well be external pressures that are putting the business between a rock and a hard place, and so a direct appeal to just stop new work for a while may not go over well.

(By all means, ask for the time, just don’t expect it in this sort of crisis situation)

So if those were the first thoughts to come to mind, try to go back to the drawing board. Assume you have a decision-making stakeholder that is at least willing to listen at this point, and that making an argument that takes the business needs into account will be well received.

What would you suggest as a first step? Try to think of something that would begin having positive effects immediately, without you having to write a single line of code.

I will share my own thoughts in a few days, but until then… I’d love to hear your thoughts!
Just hit reply to share your ideas, or catch up with me via The Practicing Developer’s Workshop.

-greg

PS: Thanks so much to the many folks who gave me feedback on the book chapters I sent out. Your comments were super helpful!

PPS: HAPPPPPPPPPY NEEEEEEWWWW YEEEEAAAR!!!