That almost all software is unreliable and SaaS products only work because there are engineers behind the scenes fixing it all the time.
The Wizard of Oz nails it:
"Pay no attention to that man behind the curtain"
The Wizard of Oz nails it:
"Pay no attention to that man behind the curtain"
That's not to say software doesn't have bugs. Only that bugs don't appear suddenly.
Most bugs are caused by two things:
(1) Changes to the code that accidentally break unrelated stuff
(2) Changes to the environment (eg. OS vendor releases a new version which changes how some API behaves)
I think (1) is more common.
So I think that the reason why SaaS have problems all the time is that typically devs are changing stuff all the time and accidentally breaking things left and right, not that software is inherently unreliable. And since users can't keep using an old version that works for them, they'll stumble across every bug eventually.
While I'm sure that some developers go rogue, this feels like a business or management issue. Teams pushed to release fast and early. I wonder how often the developers in teams that release buggy software have asked for time to improve processes and legacy code, and been denied.
If developers really are going rogue and changing code on a whim without testing processes picking it up, this is still a management issue.
It's not a management issue, it's deeper than that.
Whenever you change something, you risk breaking something. It doesn't matter if you have unit tests, integrations tests, code review, staged rollouts or whatever else. Every time you change something, you risk breaking something. It does not matter how good your QA process is.
> improve processes and legacy code
Refactors are also a major source of bugs, so you should do that only if there is a serious problem with the old code.
The problem is that the code is constantly changing. With SaaS, customers have no choice but to always use the latest version, so eventually they'll run into a bug. Because constant change means that errors slip through eventually.
With traditional desktop software, customers aren't forced to update. They can just keep using their version of the software, and rely on the fact that it's not going to break suddenly.
If a customer doesn't change their workflow, they aren't going to suddenly stumble over an old bug.
But if you keep pushing changes, eventually you'll introduce a new bug that does affect them.
There's no way around it: The more you change software, the higher the risk of introducing bugs.
That applies even if the changes are just bug fixes for old bugs. Every time you fix a bug that I wasn't affected by, you risk breaking something that I do use.
Most old desktop software is happily deleted in favor of newer versions because it's full of bugs and/or almost impossible to use, and the one that is not is the actually not too buggy one.
Today I helped a former customer build code that hadn't been touched since 2013 with a compiler released in 2010. And it just worked. Also today my coworkers dev system stopped working because Chrome didn't update properly.