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 Ny BreakingProâ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 Ny BreakingPro or Future plc. If youâre interested in contributing, you can read more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro