4 ms·
> We don't know what things we can break or deprecate, so we have to be extra careful. I'd argue that almost nobody really knows that. [1] It's just that many
by vog 10y ago
> We don't know what things we can break or deprecate, so we have to be extra careful.
I'd argue that almost nobody really knows that. [1] It's just that many developers / companies somehow get away with not being extra careful. How many libraries introduce some "unimportant" backwards incompatible change without bumping their major version number?
[1] ... unless you have a web application and really good statistics. But then, you end up being a large company like GitHub or Amazon, I guess.
- js8 10y agoThinking about it some more, conservative users are also a factor. If we change anything, we impose additional cost on our customers, which have to retest, redeploy and retrain. So it's not easy for this reason alone. When you have a platform for internal use only (or a platform that is available free of charge without any warranties), you can decide to make a change by fiat. We would like to "move fast and break things", but our customers unfortunately don't appreciate that sentiment.
- vog 10y agoThinking even more about it, many changes are "cosmetic", such as renaming fields or restructuring essentially flat structures. These may make the system more consistent and easier to understand for newcomers, but break old code for "no reason". So developers should develop some kind of taste to distinguish between "real" changes and "cosmetic" changes.