Hacker News Reader

Comment by jakobegger | Hacker News Reader

On the contrary, my job taught me that desktop software can be extremely reliable and does not actually break all the time. Many of my customers use versions of my app that are a few years old without any troubles. When the user is in control of their environment, software doesn't suddenly break.

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.

View on HN

I think it's survivor bias.

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.

I have a slightly different take: Software quality is fairly consistent. But when software changes infrequently, the user can create work-arounds for the broken stuff. When software changes frequently, you don’t have sufficient time to create work-arounds, leaving you frustrated with bugs you can’t deal with.

> 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.

> this feels like a business or 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.

That old software is full bugs, they've just figured out to work with them.

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.

I had this conversation today. The more dependencies outside your control and the less concerned the maintainers are about about stability the faster the code rots.

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.

I find a lot of "bugs" are that inconsistent / missing data gets into the system.

I do wonder if some of it is down to the platform. It seems to be a weekly occurence that I log onto an application and I'm presented with a blank page. No doubt some trivial JavaScript exception has borked the whole thing.

Reply on news.ycombinator.com