> 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.
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.
No, they just aren't affected by the old bugs. Most bugs affect only a small fraction of users, because bugs that affect many people are usually found during QA. So the majority of your users will not be affected by the existing bugs.
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.
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.