The Sad Graph of Bad Software Project Management

The number of Issue Open vs. the Close Rate Over a Four Month Period

You know those graphs in JIRA or PivotalTracker or other agile project management tools? They aren’t there just to look nice, they are quite a good indicator of whether or not a project will be successful, at least according to Gregory Brown (you can read the comments of other programmers on reddit here). He has written an article that explores the graph of the number of open issues versus the number of closed issues, the graph shows that

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.

He points out that graph doesn’t have to be a sign of doom for a project, it could just be bad project management practices:

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.

This is precisely why we at Software Dev Group consider it vital for all software developers to gain some project management skills. At the very least, all software developers should have access in the project management tools to clean up duplicate or old tickets and to prevent low priority work from entering the workload.

Take a few minutes to explore whatever project management tool is being used and try to produce a graph that plots the number of issues/tickets/stories opened against the number that have been closed. If you get the same graph that is shown in the article (pictured above), you may want to consider what options there are to fix the problem.

Additionally, you can use the graph to predict when there will be a real crisis and when the business side will be very loudly complaining about how slow things are being implemented. In the graph above we can see that within 4 weeks of working the team is already swamped with tickets, and another 4 weeks after that, the project may not go so well. This is a clear failure of the project management: there are always things to do on a software project but the project manager’s job is to control the scope of the project.

Common Reaction: Asking For Time To Cleanup

In the article, there are two common reactions by developers to the sad graph of bad software project management:

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…


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.

We have seen this play out at many organizations. Developers very often want to improve code quality because we know it will indeed reduce the time it takes to implement new features, it will reduce the time it takes to implement bug fixes. They ask for the time to do things the right way, but are almost always told there isn’t any time to developer software properly.

We have also seen the other response and sometimes even a project manager or chief technical officer or other executive will suggest that there be cleanup time or a refactoring sprint. Unfortunately, this cleanup time never seems to happen even when suggested by someone who has the political power but doesn’t have the will to make it happen.

Can We Escape The Sad Graph?

One of the comments on reddit about this article is particularly instructive about our situation as software developers:

The lone code monkey peon bumps himself against a manager who’s got all the power, ages-old office politics, nepotism, iron-clad traditions that will never be changed because “they’ve always worked”, and so on and so forth. Attempting to upset the behemoth risked a firing at best and a constructive dismissal at worst.

This is entirely the reason for the existence of Software Dev Group. We believe that we can escape the sad graph of bad project management, and the office politics. We believe we can establish software developers as professionals whose opinions and evidence-based reasoning are respected within the work environment and within the industry. To this end, we have a list of resources and in it we have a list of books and free online courses which can help us gain the skill to avoid these bad project situations (either by fixing the project or by finding new companies with less broken processes).

Gregory Brown, the writer of the article, also plans to create a workshop that shows developers and programmers how to build the leverage within a company to help make changes to the way projects are run.


Be the first to comment on "The Sad Graph of Bad Software Project Management"

Leave a comment

Your email address will not be published.