8 signs you are creating software waste

Humans are drowning in waste. You do not have to be an environmentalist to see the burden that our “throwaway” culture is leaving future generations. My own family talks about it all the time. From the Great Pacific Garbage Patch to the mountains of fast fashion rotting in landfills to swank offices sitting empty — so much of what people create ends up as trash. But as bad as the physical refuse is, there is even more virtual garbage being created every day.

There is so much waste in building software — seen and unseen, tangible and intangible.

Technology has fundamentally changed our daily work — easier, faster, and more efficient. (And in the case of AI, it even promises to do the work for us.) Software is more abundant and accessible than ever before. The speed at which we can develop new products and release new functionality is staggering.

This level of ubiquity is a relatively recent phenomenon. Software product development is still a new concept compared to other forms of manufacturing. So really we should not be surprised that the process of making software is actually incredibly inefficient at most organizations — despite all the technology. The voracious demand to make more is far faster than our ability to analyze the best way to do so.

Inefficiency is pricey. It is hard to pinpoint exactly how many features are released but rarely (or never) used. Some surveys point to as much as 80 percent. If you look at it from the customer perspective, there are estimates that more than one-third of all enterprise software purchases sit idle. This adds up to billions of dollars wasted.

There are material expenses for the business too. Going too slow can damage customer trust, leaving them wondering if you can deliver what they need. Going too fast without clear direction can devastate team morale. It starts to feel like a carnival ride, inching to the top with anticipation and then plummeting down. Waste with no care for cost leads to boom-and-bust cycles, market crashes, and layoffs.

No more software waste. For product development teams, the ultimate goal must be building what is essential and delivers value.

What is software waste, really? If you go by conventional thinking then software waste is any code, feature, or functionality that the customer does not need or derive value from. There are real costs associated with these errors, as outlined earlier. Yet I believe this definition is too narrow. And by the time you have released something, it is often too late to make a fix that helps anyone — customers or the team.

The real waste begins much earlier in the product development process. It starts with poor customer understanding and a misalignment between our hopes for what we are building and the value it actually provides. It is mired in miscommunication and bears fruitless work. There are signs that anyone who has weathered software waste can recognize:

Guessing

Being known is powerful. Yet no one on the team is clear about what customers really need and want. Folks are working off hunches and inferences rather than vetted knowledge.

Wondering

Curiosity is a good thing. Questioning what should be already answered is not. Goals are murky and the team is unsure if they are working on the right thing.

Waiting

No one waits well. There is always dead time in projects, but the emptiness feels untenable. Process is a joke. Handoffs are hamfisted. Communication is lacking.

Second-guessing

Uncertainty is the norm. Leaders are swinging back and forth from idea to idea. The whiplash leaves an ache. No one is confident about what the team is building.

Reworking

Everything can be improved. And software product development moves fast. Agile does not mean having to redo work over and over — that is a sign of dysfunction.

Overdoing

Insecurity leads to overcompensating. Knowing that the essence of what the team is delivering will not be on target, people try to polish with unnecessary flourish that does not directly benefit users.

Screaming

Tensions mount. People lose their cool due to the reality of not delivering. The team is finger pointing and blaming in anticipation of the downfall.

Abandoning

Everyone is relieved that it is over. Maybe there is some back slapping and congratulatory messages. Those backs are fully turned though. No one is measuring the value of what was delivered to customers or holding a postmortem to identify ways to improve the process in the future.

When we are deeply aware of the cost of creating products, we are better positioned to deliver the most value.

Thinking deeply and doing what you can to reject software waste is a good step. It starts with a mindset. However, I am very aware that product development teams suffering need practical guidance too. Pointing out problems is helpful but only goes so far.

So, I am working on a follow-up post with some of the ways to mitigate software waste. If you have experienced any of the above and overcome, I would love to include your experiences — leave a comment here and tell me how you have avoided the software dumpster.

Deliver real value with Aha! software — how about 30 days on us?