Interestingly, I thought that too. So when I became a manager, I put all of my corporate political clout into defending devs against ever having a hard schedule or pressure to estimate without enough info. Amazingly, it took more than a year to break the cycle: bad code, and claims of not enough time. It's like a reflex for many devs.

I constantly beat the drum for quality and the practices to enable it. but i agree with others, just the manager's actions are not the reason. As a dev I didn't let managers bully me into bad code, and as a manager just giving permission to do things right wasn't enough.

I would argue it's us developers that let the managers do this. They ask us how long we give a number. They say that's too long can you do better. Instead of being insulted, we hum and we haw and we say sure. So the managers learn that the first number we say is wrong and just to keep asking and they get a better number.

If developers gave a estimate (estimates should be ranges) and stuck to it (and delivered on it) then the managers would trust our estimates a bit more.

Sure, but I'm not convinced Joe Schmoe developer is really all that good at creating systems which can be easily extended for any requirement that may come up either. Then you have to weigh the cost of rewrites against what value they will actually have. And then you have to contend with mediocre devs who take the easy route and just declare a global.

Well I'm not convinced you ask yourself about the L in SOLID when you are doing all that extending.

Yes, because all design issues are solved by gating everything behind an interface.

Exactly, the interface being general procedure call. Oh wait... ;)

Product Managers* ;-)