My answer is that you can plan for work to be done on a deadline but you can't negotiate when it will be done with the people doing the work. It's going to take as long as it takes. It's poor management that sets unrealistic expectations and demands results.
You can plan for work by using data. You get data by tracking effort estimated versus completed and triaging bugs. You prioritize goals instead of setting deadlines. You measure and refine.
It sounds counter-intuitive to business people who think in terms of, I just sold customer X the product and they need it delivered by Y so that we can get the team paid by Z. This is where poor management decisions can sink your team. If Y is decided by the sales or management team with the customer and they didn't consult their engineering team... then they're working on another planet. The goal of processes like this are not to eliminate Y but to set reasonable expectations and objectives.
As I like to remind my business owners: you can have something that works -- it may not be the whole kit -- or you can have nothing at all. Winning is about prioritizing objectives.
One book I've read recently that taught me a lot about management is Extreme Ownership. I think there's a lot of cross-over from this book into Agile methodologies that I think non-technical stakeholders can really understand.
If I'm interpreting that fragment right, your essay is treating "programmers development time" as a fixed rate of progress (the "9 women can't have a baby in 1 month" meme) so one answer to meet a deadline is to remove features until the deadline can be met.