Software erosion is happening all around us
Would it surprise you if software developers tested their software? It may not feel like it with all the outages this year, but the average developer spends 42% of their workweek on maintenance. So what’s up with all the outages?
Crowdstrike may have made the most noise, but in 2024 fast food deliveries ground to a halt, WhatsApp and Instagram were taken offline, passengers were stranded at Heathrow Airport and there was no fresh food available at the Brexit border.
These failures didn’t happen because developers weren’t testing software. They happened because of hyper-complex software configurations – too many changes to the products by too many people for too many reasons. Many companies test code against a software architecture that no one understands anymore. It’s a horribly large Jenga tower. Add one more “feature block” and the whole thing could collapse. No one wants to touch it. No one knows how it’s built anymore. But sooner or later, an executive decides, “This product needs AI.”
That’s the eternal battle in software development: innovation versus maintenance, and it’s eroding the very foundation of the software world.
Director of Product Management and Product Marketing at Qt Group.
Why is software becoming less and less?
Like rocks and mountains, our software slowly erodes over time. If software is a rock, then developers are the wind and water that breaks it down. Thanks to the dependency hell we have maneuvered ourselves into.
So much new code is being added to codebases that affects or is affected by other moving parts of software that the complexity of products has exploded. Some of this is due to pressure from senior managers to outperform rivals, but sometimes it’s developers simply trying to shorten workflows.
A developer is asked to add a new feature. That feature blows up the codebase. The developer adds a shortcut to work faster, which adds complexity. A manager asks the developer to extend the product. The shortcut from before? It’s not compatible with the update. Things break. The developer starts patching. It takes a long time. The developer adds another shortcut and… it goes on and on.
Software erosion eventually becomes a self-fulfilling prophecy – a destabilizing chain reaction, where the smallest quality-of-life improvement is both a headache to implement and a risk to the functionality of teams in other silos.
The Human Cost of Software Erosion
If more than 40% of your development time is just keeping code alive, you are not adding value to the product. If you include meetings, time for comments and feedback, etc., you are left with less than half of your week for value-adding development.
This is staggering for a development manager, who suddenly has half the time his developers can spend on innovation. It’s even more disastrous for developers: what satisfaction and pride could they possibly get from constantly fixing code that keeps breaking? The eventual outage disaster and subsequent PR blunder are just another morale blow.
The next thing that happens is the loss of engineers who have had enough. Onboarding new engineers increases the time to market, which frustrates everyone involved. Old mistakes resurface, more people leave, except now they are also seasoned veterans. Where does it end?
Repair ‘Shift left’ yourself
There has been so much talk about “shift left” in recent years, and yet some companies have failed to understand the reason we keep harping on about that philosophy. The cyclical misery that many developers face will not end until we fix “shift left” itself.
Fixing “Shift Left” doesn’t just mean cramming more testing time into developers’ busy schedules. Some companies hire outside QA testers to lighten the load, but that’s an expensive measure. It’s like putting duct tape over the leaky holes on a deck being pummeled by warships.
A late fix is a costly fix. The least costly fix is to get your architecture right while you’re still designing it. Weave QA into your software development before you write any code, not after. If you’re just starting to prototype, QA might seem like unnecessary overhead. But when you’re building a viable business that attracts customers, you need quality code. You don’t want to lose customers in the early stages of your product life. If your product ships next week and you have to redesign your architecture to avoid a product recall, that’s a catastrophe of epic proportions. It’s going to drive up your time to market, drive up development costs, and burn everyone out.
How do you get quality code? You need multiple sources of intel. Don’t skimp on static code analysis and functional testing, which should be done as new code is written. You need to know how much code you’re cloning, where your hidden dependencies are, how your components talk to each other, etc. When you know these things and you’re doing architecture verification, it’s easier to identify problems. If you can’t do every type of test under the sun right away, that’s fine, but start building these processes out over time.
And more importantly, is your architecture actually enabling you to achieve your goals? If not, it’s time to re-architect. A company with decades of legacy code might not be able to do that, but an SMB with five years of code? The lawsuits from unhappy customers will overshadow all the headaches of re-architecting.
Also understand that different roles have different incentives. Developers sometimes resist static code analysis because it is “extra work” and adds time to projects. Who should be responsible for this? Find out early enough.
Now that outages and crippling bugs are starting to feel like a dime a dozen, it’s more important than ever to understand how the Jenga tower was built. Too few people know its architecture inside and out. With a little discipline, that can change. And it has to, because that tower is going to come crashing down soon.
We have listed the best laptops for programming for you.
This article was produced as part of TechRadarPro’s Expert Insights channel, where we showcase the best and brightest minds in the technology sector today. The views expressed here are those of the author and do not necessarily represent those of TechRadarPro or Future plc. If you’re interested in contributing, you can read more here:
