The Haskell programming language's unofficial motto is "Avoid success at all costs". Given Haskell's history as an internally consistent, academically pure language for many many years (it was practically useless until mathematicians figured out how to cram the possibility to read input and emit output into math-y notation), this makes sense.
Users, of course, do things you don't predict. They tend not to want to rewrite working code because you've changed everything from surface syntax to the most fundamental philosophy underlying foundational semantics.
Sure, I overgeneralize, but two distinct poles exist.
This tension exists in any creative endeavor which exhibits the curious quality of more than one way to accomplish something, especially when those multiple ways each exhibit somewhat intangible qualities up to and including aesthetics.
Once, a couple of well-known Perl programmers consulting through my company decided to rewrite the underlying framework of an application the evening before we were to deliver a milestone to the client. The result was better, from a future development point of view. The result took less work and provided better abstractions, from a current effort point of view. The result would have been great, six weeks earlier.
Here's the problem with software development: we don't know what we need to build until we really need to build it. We don't have infinite knowledge. We don't have infinite time. We can't devise a perfect model for a messy, complex, chaotic world that's built to slather corrosive entropy all over our best efforts from the first moment we put them in front of users.
We'd love to get it right from the start. We won't.
We'd love to get it flexible enough that we can adapt to any change with grace and ease. We don't.
This leaves us two options. Either we never actually ship, so we never have to deal with disappointing users by exposing them to the effects of inevitable entropy or we embrace the fact that entropy always wins in the long run and set up bulwarks to hold back that encroaching tide and make smart tradeoffs: in exchange for a little pain of upgrading, the next version is faster, easier to use, smaller, simpler, more powerful, less buggy, whatever form of better you want to chase.
We don't get to choose if things will change. We get to decide how we react to inevitable change and the inevitable realization that we've made mistakes.
A first-year financial education eventually discusses the time value of money, where a smaller amount of money now can be worth a larger amount in the future because of what you can do with it in the interim. The same goes for knowledge and user feedback and the ability to revise your design and implementation.
To strain a metaphor even further, knowledge and customer satisfaction compounds. Sure, you want to avoid the mistake of shipping something that doesn't work at all and chasing away your entire potential user base, but we tend not to make that mistake.
Instead, against all evidence, we hold out for the perfect and avoid shipping at all costs. What a shame, when we could gain even more benefit from embracing our imperfections.
