In my experience as a software developer, this comes down to management more so than actual engineers.

When creating a new product, management typically wants to move fast and prototype things to get feedback from stakeholders. So you end up making something messy, quickly, so that you don’t waste time building the wrong thing before you get feedback.

But once you solidify plans, you definitely want to go back and clean up what you built to be both solid enough to release, and robust enough to build upon for the next iteration.

The problem is, no matter how many times you tell stakeholders that what you’re showing them is a prototype, they don’t get it. If they see something that appears to work in your demo, then the notion that you need to hold off on all their ideas and plans, so that you can go and do some mythical sounding “clean up” and “architecture work”, sounds like a waste to them.

A good manager can set these expectations with stakeholders, and knows how to set the scope of features for each iteration before it’s time to clean up old technical debt and reevaluate the architecture to make sure it can handle the new ideas coming forward.

A bad manager will be as clueless as the stakeholders, and think that any developer who wants to “hold off and clean up the underlying layers of code first” are just being drama queens. Some of them may even believe their own bullshit when they say “let’s just do this one more thing real quickly, and THEN we’ll clean up the old stuff”.

Here’s where different types of devs come in. Generalizing, you have skilled devs who value their craft, you have newbies looking to prove themselves, and you have crappy devs who are lucky to make anything work at all.

Of those overly generalized types, the skilled devs are the ones praying for the chance to properly structure the underlying layers of code.

The newbies are shouting “I can do that” and going in to try to show management that they can do things that the whiny skilled devs are trying to delay, and the crappy devs are being assigned tasks and creating huge messes of their own because they essentially just want to make the damn thing work by hitting it with a hammer until it does.

So guess who bad management likes best? The devs who just get it done, no matter how, with no complaints about “scalability” or “sustainability” or “proper engineering”.

It makes for some fast early releases this way.

In the end, though, it just makes for a product that breaks at a slight breeze, slows down all future development, and drives competent devs away.