7 ms·
This seems like another case where jblow's opinions are guided by his experience as a game dev. Games can be "finished" and never touched again. I think I mostl
by taylorallred 1y ago
This seems like another case where jblow's opinions are guided by his experience as a game dev. Games can be "finished" and never touched again. I think I mostly agree with him that software could be made to be timeless to some degree. But, in the world of web apps and saas, the culture is to offload much of the work to third party libraries/APIs which locks you into a never-ending cycle of dependency management. I don't know if this culture is totally necessary (maybe to ship fast and keep up with security updates?), but in a world where users expect software to be constantly improving you can't expect anything to be "done". Maybe you could get close if you built everything in-house, but even still you have to keep up with security flaws.
- QuadrupleA 1y agoFrom experience - if you look at the "security flaws" in detail that updates and patches address, an app with good dependency hygiene is rarely vulnerable to them, and doesn't need the purported fixes. So in those cases it's mostly a comforting mirage that your software is improving as you do "security updates" on your libraries and dependencies, except in rare cases. And, security updates should not break your app! What breaks your app are feature changes, API changes, and the like, which is a breach of backwards compatibility and IMHO kind of lazy and hostile on the part of the library developers. It creates massive unnecessary work for developers, and unnecessary bugs and problems for millions of end users.