There's no merit to striving for elegance in everything you do. You're better off shipping 3 projects with inelegant kludges than 1 perfect one. The customers aren't going to care. The users aren't going to care. You ship more code and create more value. Everyone's a winner if you bodge things more!
Within reason.
Often these are conflicting goals too. If that guy hadn't shipped the kludge 10 years ago perhaps the company and project wouldn't exist today.
On some occasions the company folding would've been a better outcome for everybody involved in the medium term.
Further code is always flexible as the absolute worst case is to start over with all the lessons from the first system. However, code that has not shipped is not creating value.
Most engineering doesn't need to be beautiful, performant, extensible, etc. It just needs to be done.
The most common counter-argument I hear is that this view is 'short-sighted' and too focused on 'sales'. In my experience, the short-sighted view is that you already know what you need to be building. Over-investing in the problems you know about leaves you without the flexibility and agility to tackle the problems you don't know about yet.
As somebody who's building new product off a ~20 year old perl codebase, I strongly disagree. No matter how easy the problem the system you're building to solve is, architecting and implementing a complex system that will stand the test of time is itself a hard problem. And if it doesn't need to be maintained, I would argue that you're not engineering, you're hacking. Nothing wrong with hacking, but it's a completely different approach to development optimizing for different attributes (time to market vs quality).
Now, that's not to say that they don't both have their place within a given project. Hacking together a MVP and then applying more rigorous engineering practices after it's been "proven in battle" seems to be a good balance. I'd highly recommend checking out David Black's work if you aren't already familiar, he has a lot to say on the subject! https://www.amazon.com/Wartime-Software-Building-Matters-Bet...
1) did the goals get accomplished?
2) did it get done fast?
3) did we avoid accumulating critical-path tech debt? (I'd like to emphasize that only actually critical-path tech debt matters. Tech debt off the critical path doesn't matter.)
Frankly, if you have time to build a perfect solution you've allocated too much time to the task.
Clever architecture will often beat clever coding.
Sales, as boring as they are, often pay salaries, and the bills to keep the lights on to keep. As a guy who has to pay those salaries and bills, and a developer, teaching junior and "think they're not junior" devs how to find the balance between how much abstraction, architecture and coding cleverness is enough remains the most key part of what I do.
The best devs I find, especially the super experienced polyglots, still maintain a healthy distrust of their code, think about future devs touching their work, and often write enough love letters to their future selves explaining why they did what they did.
I let a lot of bad decisions that "architects" made go at my last job without putting up a fight even though I knew they were bad decisions since I knew I wouldn't be at the company long term.
As the newly installed software architect at the company I'm at now, seeing that I plan to be here for a few years. I'm much more likely to fight the good fight about doing things right instead of fast.
Actually, I think doing things right and doing things fast is a false dichotomy. You can do things right, fast, and deliver the minimum viable product. I can't think of a single bad architectural decision that would help you in the short term over doing it right.
The problem with good enough is that my opinion of it differs from yours, in possibly very important ways. Good enough to you may mean it compiles and executes 'happy path' logic just fine. Good enough to me means it's at least lightly commented, the code is formatted and indented properly (sidebar: THERE ARE STILL PEOPLE WHO DON'T DO THIS!), maybe a smattering of unit tests to prevent regression, and the code is semi-coherent (no spaghetti).
Now, most of what I consider good enough has little to do with if it executes more functionality than just getting it working. But in the real world, the lack of the other things I mentioned will ALWAYS cost me more money when I inevitably have to come back to the project months down the road.
The converse is also wasteful. Don't go re-inventing a CMS because you have a couple of web forms and you want to make a universal system so that all forms can be accounted for going forward. Keep it simple, but robust. Build the couple of forms, don't pigeonhole yourself, make a note that if we get over a certain amount of different forms it may be better to have a generic system underneath, etc. Don't over engineer it. Engineer for the things you know you have to handle given the current requirements, don't engineer for the things that will happen if you reach 10x volume (you likely never will).
Well written code doesn't take more time than poorly written code. Even if deadlines demand skipping unit tests, you can still write your code to be unit testable.
I'm the lead dev at the company I'm at now and basically have a clean slate and empty repo. I get to design code using best practices. I've already found that not taking shortcuts has allowed me to reuse code in a ways I never imagine.
I don't want to curse my 2017 self out in 2020 because of bad decisions I made.
True in 2020 I might look back on decisions I made in 2017 and kick myself, but I will have small focused microservices, decoupled classes, and a full suite of automated tests to allow me to refactor aggressively.
Even to the point if in 2020 I decide that one service should be rewritten in TrumpScript, I have automated Newman API tests that will allow me to rewrite the whole thing and have a level of confidence that it will work.
I get the chance to instill a culture of doing things right is more important than doing things fast.