Fixed time and fixed scope is essentially impossible, except in trivial cases. What I read the author saying is that he chooses to make it fixed time and has flexibility around scope in his work, because the requirements are more like loose descriptions than a description of exactly what a product should do, while ignoring edge-cases. That sounds like a nice situation. And a perfectly fine way to manage an engineering team. But it also sounds a bit to me like an abdication of responsibility to the engineering team by product, to allow the engineering team to decide what exactly the scope is. Again, that’s a perfectly good way to do it, but it means that product can’t come back and say “that’s not what I was expecting, you didn’t do it.”
I don’t think the author really tackles estimation here, nor the reasons why estimation is a hard and controversial issue, nor what junior engineers are looking for when googling “how do I estimate?”
The real reason it’s hard in this industry is that in general, product controls both scope and time, which are the two major dials by which delivery is managed, but abdicate responsibility for them by going an ill-defined but nonetheless more fixed (and unyielding) scope than described in this article, then demanding engineers give them specific date estimates to which they’ll commit, and work free overtime if they turn out to be wrong.
The author correctly defines a way to resolve this conflict: give engineering more say over scope—but fails to recognize that the root cause is not poor estimation, but rather that product or management denies engineering much say over scope past the initial estimation, and then demands they set fixed dates they commit to before enough is known. Death march projects, in my experience, are generally a failure of product, not engineering.