I feel this is a bit more nuanced. You need to account for what is likely/possible to happen in the future. There's no "easy to change" that remains that way. To give a specific example, I've recently created some small apps for automating interaction with a terrible-enterprisey-crud software. The first one was written as a quick script. The next one had some organisation but remained a crappy script. The next one as well... The problem is that now I need to maintain the previous scripts for a very long time. Every new app I make now abstracts the windows it interacts with into separate controller classes. I made the change in my approach too late and it's both too much work to rewrite everything written initially and it's really annoying to support it too.
I know it's a bit of a hindsight thing, but the time to change the approach was when I was about to write script no 2. I should've invested a little bit of time into research and proper structure, but didn't. A bit of complexity saved me in later development...
“Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” -Blaise Pascal
Complexity is not planned, it is created though expediency. Devs use that database because they’ve done it before, they know how to use it, and they have a bunch of code segments to reuse. It gets them one step closer to solving the problem. An elegant solution, presumably some form of binary serialization, would require a learning how, and maybe rethinking objects to strip out cruft and make serializable state, and then coming up with an efficient access pattern. All these things are nice elegant composable tools available somewhere, but not at the top of mind like MySQL, which you’ve been using since your first programming course.
I’ve been doing a lot of work with C++20 templates recently. The simplicity and reasonability benefits can be enormous, but the time it takes to learn, design, and craft them is completely oblivious to the person reviewing the code, if it ever gets reviewed at all. In a corporate setting, the only thing anybody sees is lines of code. Remote work has strengthened this anti-pattern. Nobody sees the time or diligence with which you craft solutions. Elegance looks like nothing.
I've learned that maintenance is way more important for most of my use cases. Most people aren't doing stuff that requires real-time processing so my assumption is that maintenance is more important for most others as well
I know it's a bit of a hindsight thing, but the time to change the approach was when I was about to write script no 2. I should've invested a little bit of time into research and proper structure, but didn't. A bit of complexity saved me in later development...