That last 1% sounds like a godawful lot of work. With this attitude, you can never call something "done", and I deeply hate this notion of "things that are never finished". Like "you are never done learning C++". It implies that everything you do will haunt you for the rest of your life, that everything you do is a liability, and that there is some moral code or obligation to developers to do things because it is convenient to other people.
This, together with the ever-increasing complexity of well, everything, and the increasing number of "things developers should know about X", together with the notion that developers should always work fulltime and learn in their own free time, is non-sustainable.
It's a painful fact that in this "modern" environment, we just can't build anything anymore. There have been three critical vulnerabilities just today (Downfall, TunnelCrack, Inception). If you make a website it's probably hundreds of kilobytes big and you get people whining over accessibility and how it breaks dark mode of version 23.42.23 of their obscure browser.
Have you ever noticed how productive people like Fabrice Bellard just don't care about that stuff? The last procent is just a trap to suck you into the tarpit of spending time on useless shit. Choose a stable target and reasonable feature set, release, and never touch your project again. Bliss.
I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.
If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?
You limit builders by forcing anything they build to hold an alpha/beta/preview label, where it doesn't graduate to having the full backing of the company if maintainers can't fill in the rest of what's necessary for long-term maintenance. The incentives revolve around how many "builder" projects eventually end up losing the alpha/beta/preview label and how long it took to lose the label.
Maintenance concerns should be part of the requirements for the project to be considered successful, the same as pretty much any other engineering. If the only reason to have SEs care about maintenance is to have them do it later, then incentives are wrong.
Communication between the builders and maintainers, including "costly signals" (commercial consequences for poor work, poor reputation, losing contracts etc). There are a lot of builders out there.
This, together with the ever-increasing complexity of well, everything, and the increasing number of "things developers should know about X", together with the notion that developers should always work fulltime and learn in their own free time, is non-sustainable.
It's a painful fact that in this "modern" environment, we just can't build anything anymore. There have been three critical vulnerabilities just today (Downfall, TunnelCrack, Inception). If you make a website it's probably hundreds of kilobytes big and you get people whining over accessibility and how it breaks dark mode of version 23.42.23 of their obscure browser.
Have you ever noticed how productive people like Fabrice Bellard just don't care about that stuff? The last procent is just a trap to suck you into the tarpit of spending time on useless shit. Choose a stable target and reasonable feature set, release, and never touch your project again. Bliss.