At least in a private industry context - tis is the #1 reason how developers often justify over-engineering. Actually, vast majority of software either never ships or fails to achieve any meaningful use / market leadership (i.e. no one buys it), because the engineering team was too busy future-proofing it. The truth is, your software is most likely to become irrelevant lightning fast (remember the 90s?), and you should consider yourself lucky to incur maintenance debt :)
Cutting corners in order to move fast means that later on, when you're dealing with competitors and upstarts trying to take your place, you can no longer move fast enough because of all the technical debt you incurred early on.
> An apprentice painstakingly smoothing an invisible surface would be yelled at for wasting time. An apprentice failing to smooth a visible surface would be yelled at for producing crappy work. To become a professional, the apprentice learned to work efficiently but still do a good job.
yes but... if you don't deliver, there won't be no future for product. anyway, every single product out there got major overhaul/complete rewrite every few years/versions.
I think this often boils down to key people's personality traits - to have everything possible under control. can work on smaller parts/projects where it delivers well, but once applied at large scale can fail spectacularly.
I wish I could say what that magical silver bullet is, but it's specific per case - a fine balance of effort/real value, with just enough resilience to not fail too fast. or maybe not.
> every single product out there got major overhaul/complete rewrite every few years/versions
That's just wishful thinking. Most products do not go through a complete rewrite. They may change dramatically over time, but that's typically due to incremental changes, not a from-scratch rewrite.
For context, I'm working on a project right now that has a reasonable amount of technical debt incurred at least 4 years ago. We're eventually going to have to rewrite big chunks of the app specifically because those parts aren't very maintainable. If they had been written correctly the first time we wouldn't have this issue. And in this case, it shouldn't have been hard to write it correctly; doing things right does not necessarily mean doing them slower.
The issue is, people rarely build the right product on the first try. Your reasoning here assumes that the thing you've spent time building well was the right thing to build. It's worth getting things out quickly initially to find out if anybody wants it. You don't want to compromise the experience of your product (external). Thus it's best to sacrifice features and reduce complexity, in order to test ideas and the quality of product experience. Writing code is just a means to this end.
You're talking about something completely different here. Putting out an MVP is not the same thing as writing sloppy code that becomes a maintenance burden later.
