[andreasklinger]

Everyone will say no to this question. And it's the right answer.

But then you run into team problems with engineers feeling very exhausted working with your codebase and you have to constantly deal w/ missing confidence in the developed software.

In my experience "Acknowledged technical debt" is usually a good middle ground to work with. It usually also works with die-hard engineers.

Building software is not about writing optimal code. The goal is to have confidence in the code you wrote. Constantly wondering how something works only to realize that it doesn't is energy draining and needs to be avoided.

Acknowledge and document technical debt. Explain (in notes) how stuff is meant to be, how it should be, what does work. Essentially you want to reduce the amounts of "WTFs" the next person (eg future you) has reading the code.

The most important lesson here is: technical debt can be a good thing. You buy expensive short-term impact with future time. Very often you never need to "cheque" that future time because that part of the product might have been thrown away.

[iconnor]

I like this answer. Acknowledged debt is the most you should aim for. The last thing you want to do is have a wall of trust where you throw requirements over the wall and then don't care how the code gets written. The code is everyone's responsibility. Everyone should be willing participants in the process (which includes acknowledging the debt it took to meet deadlines).