When the Backlog Becomes the Graveyard

Anyone who has spent time troubleshooting software will recognise the frustration of finding an error message that tells you almost nothing.

“Unable to complete request.”

That might be technically correct, but it doesn’t explain what went wrong. The request could have failed because a service was unavailable, a network connection timed out, a firewall blocked communication or something entirely different happened.

Now compare that with a more useful message:

“Unable to connect to 192.168.1.50 on TCP port 8096. Connection timed out. Check that the destination service is running and that firewall rules allow the connection.”

The second message doesn’t necessarily identify the exact cause, but it provides enough information to begin investigating. Instead of spending hours trying to understand what failed, someone can immediately check the relevant service, network connection and firewall configuration.

It might seem like a small distinction, but good diagnostic information can make an enormous difference. It can reduce investigation time, avoid unnecessary escalations and sometimes allow users to resolve problems without contacting support at all.

So why is something so useful often treated as a secondary priority?

When Small Improvements Become a Large Problem

I’ve seen situations where technical investigations regularly identified opportunities to improve logging and diagnostics. The immediate problem would be investigated and resolved, and an improvement request would be created to make similar problems easier to diagnose in the future.

The process made sense. Every investigation was an opportunity to learn something and improve the software.

Unfortunately, the improvement requests didn’t always lead to improvements.

Over time, hundreds of tickets accumulated in a queue, some remaining unresolved for years. The problems had been identified, the required improvements documented and the information passed to the teams responsible for the software. But there was no effective mechanism ensuring that the work progressed.

Eventually, colleagues started asking why I continued raising improvement tickets when nothing ever happened to them.

I understood their frustration, but I continued because the problems were real and the process existed for a reason. What concerned me wasn’t simply that the tickets remained unresolved. It was that people had stopped expecting anything to happen to them.

When people start questioning why problems are being reported rather than why nobody is fixing them, the failure of the improvement process has become normal.

And that is a much bigger problem than poor logging.

The Hidden Cost of Postponing Improvements

There are legitimate reasons to postpone technical improvements. Development teams have deadlines, customers need new functionality and resources are limited. A logging improvement that might take a few hours can reasonably lose priority to something more urgent.

But when hundreds of small improvements are repeatedly postponed, they eventually become a substantial body of work. Something that could have been addressed relatively easily when first identified may become much harder to justify once it requires months of development effort.

Meanwhile, the cost of leaving those problems unresolved continues. Support teams may spend hours investigating recurring failures. Developers may repeatedly diagnose issues that better logging could have exposed immediately. Customers may wait longer for resolutions, and confidence in the software can suffer.

There is also an organisational complication. The department responsible for implementing an improvement isn’t necessarily the department receiving most of the benefit.

Engineering must allocate development time, while Support, Customer Success and customers may experience much of the improvement. From an engineering roadmap perspective, postponing the work might make sense. From the perspective of the wider organisation, the recurring cost of not doing it could be considerably higher.

Both perspectives can be valid, but someone needs to understand the total cost rather than allowing each department to optimise its own priorities independently.

Otherwise, an improvement that was affordable when identified can eventually become part of a backlog the organisation can no longer realistically address.

The Leadership Decision Behind the Backlog

In my earlier article, Do Leaders Design Technical Debt?, I explored how leadership decisions can contribute to the technical debt organisations accumulate. I think the same principle applies here.

Not every postponed improvement is a mistake. Sometimes customer commitments take priority, budgets are constrained or teams simply don’t have the capacity. Leaders have to make those decisions, often without an attractive alternative.

But good leadership isn’t about avoiding difficult trade-offs. It’s about understanding what is being sacrificed, what is being gained and who will eventually pay the price.

There is also a difference between documenting a problem and documenting the decision to continue living with it. An improvement ticket explains what should change. It doesn’t necessarily explain why the work was postponed, what consequences were accepted or when the decision should be reconsidered.

Without ownership and periodic review, temporary compromises can quietly become permanent operating conditions. And the organisation ends up with a backlog that records problems without providing a meaningful way to address them.

Although my examples come from software, I don’t think this is exclusively a technology problem. The same pattern appears in finance, operations, HR and almost every other part of a business. Manual workarounds, outdated processes, unresolved complaints and postponed improvements can all accumulate into obligations that become increasingly difficult to address.

The common problem isn’t the backlog itself. It’s what happens when temporary compromises become permanent without anyone reconsidering their cost.

Applying the Lessons to Media Control Tower

More recently, I’ve been developing my own software project, Media Control Tower (MCT), and it has given me an opportunity to look at the same problem from a different perspective.

While exploring similar products, I’ve encountered complaints from users who struggle to find useful information in application logs when something goes wrong. Some also describe difficulties getting responses from support. That combination can leave users with very few options. They cannot easily identify the problem themselves, and they cannot rely on someone else to investigate it for them.

Having spent years dealing with technical investigations and customer escalations, I know how much difference good diagnostic information can make.

It has also made me think about the relationship between software quality and user independence.

If MCT cannot connect to a media server, I don’t want the only available information to be “Connection failed.” I want the application to provide enough detail to understand what happened, what it attempted to connect to and what might have prevented the connection.

That doesn’t mean every user needs to understand technical logs. Ideally, the application should provide a clear explanation for ordinary users while retaining enough technical detail for someone investigating a more complicated problem.

Of course, developing software also means facing competing priorities. There are always new features to build, existing functionality to improve and limited time available. I can appreciate how easily something less visible, such as logging, might be postponed in favour of something more exciting.

But that is precisely why I want to treat diagnostics as part of the development process rather than something to address only after problems begin appearing.

Good logging isn’t simply about helping developers investigate failures. It can help users solve problems independently, reduce support requirements and make software easier to maintain over time.

And when improvements do need to be postponed, I want those decisions to be deliberate rather than forgotten.

When the Backlog Becomes the Graveyard

Looking back at that old improvement queue, the most concerning part wasn’t the number of tickets. It was that people had stopped expecting the process to work.

The problems had been identified, the investigations had produced knowledge and the improvement requests had been documented. But the connection between learning something and improving the software had broken down.

I don’t believe every backlog needs to be cleared or that every improvement deserves immediate attention. Some requests become irrelevant, others are superseded and some simply don’t justify the investment.

What matters is that those outcomes result from informed decisions rather than neglect.

A backlog should help an organisation understand what it has learned, what remains unresolved and what it has consciously chosen to postpone.

When nobody owns those decisions, nobody revisits them and people stop expecting improvements to happen, the backlog is no longer serving that purpose.

It has become a graveyard.