Comment by _bxg1
7 years ago
Except it means unbounded growth in complexity, which inevitably leads to, among other things,
- More bugs
- More vulnerabilities
- Increasing cost of support
Which absolutely impact the customer experience, just not in the short-term. A little bit of short-term friction averts long-term intractability.
That's true: those things do negatively affect customer experience. However they don't affect customer experience as negatively as the experience of having their software break.
To put this in another context: newer building codes may result in better and safer homes, but it'd be extremely user hostile to force homeowners proactively upgrade their homes to compliance each time a new version is released (at the threat of having their home condemned if they do not). The sensible compromise, in buildings and software, is to allow things to be upgraded over time, as they're modified.
From the OP: > declining concern for the future in comparison to the present
Breaking backwards compatibility has a larger negative impact in the _present_ than the cruft of old APIs and code. But that impact is temporary. However, the negative impacts of cruft can have a larger impact _in total_ over the entire lifetime of the operating system.
> However they don't affect customer experience as negatively as the experience of having their software break.
They affect it far worse, because they affect _every_ user. Having unmaintained/outdated software break only affects the subset of users that want to use that particular software.
You know the saying about how no Excel user uses more than 10% of its features? But everyone uses a different 10%, so ~100% matters? I defy you to find me a business, or probably even a human, more than 2 years old (using computers for more than 2 years) and not using any "legacy" applications. We maintain compatibility for everyone, because everyone uses it.
9 replies →
> A little bit of short-term friction averts long-term intractability.
It's not a bit of short-term friction, it's constant friction. As long as development is continuing, there's always something about the API that can be improved and would really pay off if only that was actually its final state and not just the next step until we find a good reason to break it again.
Except it may or may not be a only little bit of friction, depending on the breakage, and it is not short-term if it happens regularly.
Right - maintaining backwards compatibility is deciding to take on additional technical debt.
I think the implicit calculation here is that if you push a release that breaks the user's workflow, they can point to a specific point in time where things became frustrating and there will be a PR hit at that moment in time.
If instead you maintain compatibility, the small costs of all the technical debt accrue over time to make the experience worse than it might otherwise be, but users may not even notice or have a conception of what they may be missing for having stayed on this path.
They ultimately may end up with a worse product / UX, but they have no specific reason to complain about it.
You forgot lower performance.
"among other things" :P