4 ms·

Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely ove

Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely over-complicated architecture that has never been rethought in the past decade+. It's a cultural issue where we think major faults "just happen" and are not directly tied to prior product decisions, and therefore there isn't much accountability. But if you propose a major refactor, there is no question about (rightly) where the blame lies.

ravenstine 3y ago
Modern software is so buggy, but it's considered the norm. I was talking to a non-technical person recently about that, and although they were at first puzzled by my view that most software is problematic, they realized that they experience the same bugs I complain about all the time. It's become so normal that people hardly notice it, but that doesn't make it better because bad software wastes human life time whether they realize it or not. > But if you propose a major refactor, there is no question about (rightly) where the blame lies. LOL Yep. Worse is when the blame lies on the semi-technical cofounder of your company who, granted, achieved quite a lot on their own, wrote a barely maintainable mess. Do you really want to be the one to indirectly point out that his code needs to be replaced? Haha I think a lot of developers would rather wait for the Dilbert Principle to kick in so that the cofounder gets out of the way enough for significant changes to finally be made.