3 ms·
> 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 somethin
by jakobegger 7y ago
> 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.
- UK-Al05 7y agoThat old software is full bugs, they've just figured out to work with them.
- jakobegger 7y agoNo, 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.