If you're building a quick demo of a product to get user feedback, and you write perfect code that's highly maintainable, you've wasted time - better to throw together something as quick as you can and rebuild it if it's actually going to be used by/sold to customers. That's really overengineering in my mind - doing a poor job with the quality/speed tradeoff given the purpose of the thing you're building.
In my experience, this is a trap.
The demo almost always becomes the product, because upper management sees the demo, and says "Hey! It's almost done! Let's ship!"
This is how you end up with these gigantic Frankencodebases.
These days, my test harnesses and demos are generally "ship quality." It also means that I can mine them for snippets, without holding my nose.
I have spent a great deal of time, however, practicing, so that I write top-shelf code, by habit. These test harnesses are often churned out very quickly.
Any time I thought I could shortcut my way to a demo by relaxing on perfect code/maintainable code it has always ended up taking just as much time and often longer.
The initial version took M hours to develop, and the refactor took N hours. If I had done it right the first time, it would have taken L hours, where M < L < N + M. But it's not hard to construct legitimate business scenarios where the "N + M" solution is better than the "L" solution in terms of meeting the business goals.
It also depends a lot on the business context, whether you can trust leadership to respect technical debt or not.
My first big assignment on my first job I presented a demo ~1mo into a 3 mo project. It didn't persist data, or work on more than one host, and it saved state to a json file on the one server I manually copied the executable to. Everyone is the demo doesn't see that, they see it working as expected. The first question I got was why can't we ship this today, it appears to work as expected?. PMs, SDMs, etc care a lot less about the "it takes a while to set up something that scales, and stores data in a safe encrypted database, etc" when they see something that works.
Now whenever I do a demo like that I append "DEMO DATA:" to any visible string, and ensure I demo at least one failed behavior, just to guarantee that no one thinks it can be shipped that day (if I know it can't).
Most C-suite folks, these days, are running leveraged up the yin-yang, financially; so I suspect that "tech debt" is almost meaningless.
I'm trying to remember if I have ever known an [American] manager, that gave the slightest damn about tech debt...
...
Nope. I got nothing.
“Good judgment comes from experience. Experience comes from bad judgment.”
