There are multiple ways to make a project fit into a deadline: - change/reduce the scope => lowers the value of the product - cut corners: for ex. skip testing, ignore bugs, work faster, skip code reviews, etc. => lower quality - work longer hours (lower quality + human cost) - throw more resources at the problem: may scale poorly if at all, as well as usually results in lower quality and more friction, aka human cost

It's all about weighing everything and making the right trade-offs. Sometimes short term solutions are the right approach, maybe you need a POC more than a polished product to get that next round of funding or something.

I've struggled with that in the past, and next time I'm presented with this kind of project, I'll clearly explain the trade-offs, for example translating lower quality to: this may increase the number of bug reports significantly, increase the maintenance cost, prevent the addition of other features with significant overhauls, this and this engineer may start looking for another job, etc.

It's incredibly common and a sign of poor management and structures I have no desire of working with.

It's also what most "agile" environments end up turning into: a bunch of inflexible arbitrary deadlines designed to make developers work more, amongst many other problems.