> Personally, in my own career, I’ve found this “come correct” mindset is used to justify unnecessarily flexible solutions to allow for easier changes in the future … changes that 90% of the time, never actually materialize.
Worse, after 10 years, flexibility is required in an unforeseen dimension and a rewrite is needed anyways.
In other words, when the basic assumptions of that fancy abstraction are just not workable with the future requirements, you're hosed. Worse, now you might need to refactor a lot of code building on this abstraction.
That's why I prefer composition wherever feasible. Easier to repurpose when the crystal ball is not working correctly.
After 30 years programming, I still agree with this take. The crystal ball is inconsistent. The one certainty is that you'll understand the problem better with time and experience. And your code is the easiest to change when its small and simple. You often have to implement the code wrong in order to figure out how to implement it right.
The OP mentioned they didn't assemble their bed frame for 6 months after moving in. Thats a perfect metaphor - writing software really is like furnishing and caring for a home. Code is both content (what your program does) and environment (where you do it). If you don't take the time to care for your home or your software, it'll become a mess in short order.
I like to think about gardening metaphors with good software. Sometimes we just need to tend the garden - remove some weeds, and clean things up a bit. You can tell when thats needed by gazing out at the garden and asking yourself what it needs.
Personally I'm not very good at maintaining my apartment sometimes - I bought some shelves that I didn't install for well over a year. So whenever I have that urge to tidy up and do some spring cleaning, I jump on that instinct. Last week I removed a few hundreds of lines of code from my project (because the crystal ball was wrong). It was a joy.
Not all code is the same. Who's using the code? You, your department internally, or your clients?
How many times does the code run? Daily, monthly, once and maybe never repeated again?
How resource intensive is it? Does it take a second or a month to execute?
Do you know from the start where you're going to end up? If it's a research problem, probably no. Then you don't need to prematurely optimise the code.
Worse, after 10 years, flexibility is required in an unforeseen dimension and a rewrite is needed anyways.
In other words, when the basic assumptions of that fancy abstraction are just not workable with the future requirements, you're hosed. Worse, now you might need to refactor a lot of code building on this abstraction.
That's why I prefer composition wherever feasible. Easier to repurpose when the crystal ball is not working correctly.