ClickCease Why Is Reliable Software Surprising?

Join Our Popular Newsletter

Join 4,500+ Linux & Open Source Professionals!

2x a month. No spam.

Why Is Reliable Software Surprising?

by Joao Correia

June 28, 2024 - Technical Evangelist

Software comes in all shapes and sizes: monolith applications, small utilities, run-of-the-mill middleware, web platforms, mobile apps, etc.. But it seems like finding one that actually “just works” as advertised is increasingly difficult.

 

A Pleasant Surprise

 

Recently I had the opportunity to participate in a round of talks with some of our partners and customers, to gauge satisfaction and obtain feedback about our products. A common repeatedly kept being mentioned as relevant – “your software [referring to KernelCare Enterprise] just works. We deployed it and never really worried about it afterwards.”

Now, my obviously very biased opinion is that “well, of course it works.” But that was barely scratching the surface. The real issue is that this was a relevant fact in itself – software working as intended, with no strings attached or weird edge case scenarios, seems to be so uncommon that it’s noteworthy when something “just works.”

Think about it: how often have you used a piece of software in which you didn’t have to fight poorly defined default settings, ill-advised options, weird interactions or some hard-to-reproduce bugs triggered by someone coughing slightly loudly in the next room?

 

Why Is Software Unreliable?

 

This is more tricky to define than what it looks like. The first, and most obvious answer, is that it’s just too complex to create. There’s an increasingly complex number of parts necessary to achieve even the most basic (by today’s standards) feature set, so even the most basic applications are using multiple frameworks, libraries, and third-party code that wiring it all together reliably without unforeseen consequences is a difficult task.

The problem of growing complexity is particularly tricky to address, because as code gets more and more complex it would require more and more brain power to solve. The human brain is not evolving fast enough to compete, so you’d need to throw more brains at the power. It turns out that we don’t seem to have enough developers to throw at the problem in any meaningful way. As a result, we’re letting complexity grow unchecked.

But that’s just an aspect of software unreliability. Another interesting aspect is that software development cycles, while more complex, are also under increasing pressure to be shorter and faster. Like pouring gas onto an open flame, it’s another sure-fire way of introducing flaws in the code that lead to faults in the program.

But surely our testing methodologies are also evolving and catching more bugs before hitting production? Well, not at the same pace. It’s true that software testing, as a subset task of software development and an integral part of the software development cycle, has also evolved. Better tools and better practices make testing and bug identification possible earlier in the process, ideally at a stage where it can still be addressed without crippling delays to delivery dates. However, it’s fighting directly with the complexity and shortening cycles directly, and, again, it’s not enough to fix every problem all the time.

We also tend to expect software to run for longer than its intended lifetime. An application designed, developed, and released this year, with a strong deployment base, will likely still be in use somewhere, somehow, within 5 or 10 years. That requires maintenance. Not necessarily adding new functionality, but plugging the holes that will inevitably appear over time, if from nothing else, then from unexpected and unpredictable interactions with other software over the years. That maintenance work is performed by people coming from the same, already scarce, pool of talented developers that are writing software.

There is also a growing concern with cybersecurity that wasn’t around 10 years ago. More software is being probed for vulnerabilities, and more of those vulnerabilities are being discovered in the unlikeliest of code. This fact compounds the reliability problem by turning that unreliability from a useability problem to a security one.

And this isn’t even a new problem. We (“we” as in the collective IT space) have been worried about software reliability for decades (so much so that even sources for even earlier reliability research works are now broken and much of it predates the Internet).

Any Ideas on How to Fix It?

 

To put it simply, we need to make more developers, and the biological way of doing so seems a tad slow to properly solve the problem existing today. Barring that, the viable alternatives will likely involve some combination of reducing complexity in software development – by reducing the scope of applications, for example. Not all applications need an AI component, or even an online one for that matter.

The possibilities for reducing complexity in software development are numerous: making sure that business decision makers are aware that it’s better, for multiple reasons, to take longer to develop and release applications that are resilient and more useful than rushing code out the door as soon as a minimally viable feature set is achieved, which in turn lets developers have more time to test and catch problems; automate tasks that can be automated already by using existing tools and methods rather than trying to reinvent the wheel for every single application, like, for example, updating mechanisms that are different per application when they shouldn’t, and have no reason to be; and adopting a cybersecurity posture that privileges more reliable software over the latest-and-greatest hype of the day.

But truthfully? We like the shiny blinky lights of everything new. We board the next hype train with just as much enthusiasm as the previous one, following empty promises and disappointing deliveries. And then we complain that things don’t work as they should, and are surprised by the uncommon examples where reliability is a defining characteristic. 

It’s an interesting environment where something that should be mundane becomes relevant enough to shine. 

“It just works” –  we take it as a compliment.

 

Summary
Why Is Reliable Software Surprising?
Article Name
Why Is Reliable Software Surprising?
Description
Software comes in all shapes and sizes. But it seems like finding one that actually “just works” as advertised is increasingly difficult.
Author
Publisher Name
TuxCare
Publisher Logo

Looking to automate vulnerability patching without kernel reboots, system downtime, or scheduled maintenance windows?

Become a TuxCare Guest Writer

Mail

Help Us Understand
the Linux Landscape!

Complete our survey on the state of Open Source and you could win one of several prizes, with the top prize valued at $500!

Your expertise is needed to shape the future of Enterprise Linux!