The world's software is eroding
It’s not just you. The world’s software is feeling a little unstable lately. If it wasn’t the Crowdstrike outage that tipped you off, it was probably the many other outages this year, stopping burgers from being served, stranding passengers at Heathrow Airport, and delaying fresh food at the UK borders.
Did all those outages happen for the exact same reason? No, that wouldn’t be a fair assessment, but if there’s anything these outages tell us, it’s that something’s amiss in how our industry maintains software. You’d be forgiven if the headlines have you believing not enough maintenance goes into software. It’s actually the opposite. In an average developer work week of 41.1 hours, 42 percent of that time is dumped on maintenance, and over a third goes to dealing with technical debt.
SEE ALSO: CrowdStrike -- what went wrong?
So much time ‘fixing’ instead of innovating. And yet, most developers find themselves staring more and more at a comically large high-stakes game of very unstable Jenga. No one understands how the tower was built. No one wants to risk being the one who brought the tower down. But somewhere in the background is a stressed-out senior executive saying, “now add AI to it.”
What software erosion look like
Rocks erode. Mountains erode. And yes, now our software is eroding, too, except in this case, it’s not wind eroding software. It’s mountains of complexity fading away the inner fabric and structure of software.
It’s the complexity from new dependencies constantly introduced between different parts of software (we don’t call it dependency hell for nothing). It’s the complexity of unnecessary new code added to a codebase that then spirals into something so unwieldy, it’s almost impossible to read, maintain, reuse, or build upon. And that can even compromise the functional safety of a system.
It’s not like developers don’t know how hard it is to navigate these bloated codebases. That’s why they often write in ‘shortcuts’, or workaround ‘hacks’ to speed up their workflow -- sometimes because they have to. This sadly has a cost that is compounding over time.
The road to new features is coded with good intentions
Our tech industry is asking developers to lay down train track while the tracks behind them disintegrate. They add new features, which bloat the codebase. Developers add shortcuts to work faster -- again, unintentionally bloating the codebase. Senior executives then ask those same developers to update one part of the product -- except, wait for it, the dependency that was supposed to be a shortcut breaks the update. The developers switch to maintenance, which takes a frustrating amount of time, leading the developers to add… oh look, another shortcut!
This makes software erosion somewhat of a self-fulfilling prophecy. It snowballs over time, and as soon as the software architecture bloats past a certain threshold, reworking any aspect of a product risks breaking things for teams in other silos through a destabilizing chain reaction. Even the simplest new quality-of-life feature becomes a pain to implement, and that’s bad news for long-term efficiency and scalability.
The lessons of ‘shift left’ have not sunk in
How do many companies try to address bugs today, you ask? With a very costly band-aid over a gunshot wound. They add time to developers’ schedule to fix bugs, or hire more QA professionals. This doesn’t treat the source and just turns into a long-winded game of whack-a-mole and new bugs that didn’t exist before the fixes.
It’s ironic, really. We’ve talked ourselves to death about ‘shift left’, but the amount of time being dumped into maintenance suggest the lessons of this philosophy have yet to take hold. It’s a lesson for anyone building the products of tomorrow to tightly integrate QA into development from day one, starting with design, not after all the code is already written.
Static code analysis and functional tests should be run as new code is written. More than that, developers should have multiple sources of insight to draw from about their software architecture. When you run static code analysis and understand where you’re cloning code, or you run your architecture and understand where your dependencies lie, or you obtain results from your functional tests, that’s when you start to understand where the issues are. Maybe you can’t do everything right away, but rich insight should be the goal.
If that’s still not working, it’s time to ask yourself the high-level questions: How do your components communicate with each other? What would the first component you define in your product even be? More importantly, does your software architecture still serve you? It should not be the other way around. If it is, it’s time to think about re-architecting. For a large company with two decades’ worth of code behind them, maybe that’s not super feasible, but for a smaller web-based firm with two years’ worth of code? The short-term pains are sometimes well worth it.
Too few people today understand their implemented architecture, but if you learn to understand it, then you can finally build new features in accordance with how your software architecture was intended to work in the first place. And if you do re-architect, don’t do it without committing to ‘shift left’ QA processes. Otherwise, you’ll be back at square one, and pretty soon, that Jenga tower is going to look pretty shaky again.
Juan Rodriguez is Director of Product Management and Product Marketing at Qt Group.