The key part here is that you shouldn't be afraid of throwing parts (or even throwing wholes) away. Many times we get too attached to solutions to the wrong problem because that's what we built.
So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.
Yep. It’s fine to explore the problem space by coding. It’s not fine to think you already have the solution and end up coding yourself into a dead end. Ie. solving the wrong problem.
Yeah I believe this was identified as the main thing leading to the log4j debacle; they intentionally kept the offending code in there for backwards compatibility and edge cases, which really should have been thrown out a long time ago forcing users to accommodate the update or remain knowingly compromised.
While what you say is true, the context is a little bit different. Java built its whole world on the premise that you write your code once, and you run it everywhere [forever]. Every single breaking change loses you a bit of customers - I suppose Java just cared more about keeping their customers, rather than keeping their customers safe.
So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.