> Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side.

My heuristic in this case is just to go with whatever option is simpler, and gives us the most flexibility to course correct in the future if we turn out to be wrong.

Basically make it clear that in the absence of sufficient data to decide on the best course of action, we are being intentionally non-committal. Then outline what new information would be required for us to make a more informed decision one way or another (e.g. an actual customer asks for the hypothetical feature that we are discussing, or performance is insufficient, etc), and what actions we would need to take to change course. When put like this, I find that everyone in the room usually ends up pretty satisfied with the plan.

I think author misses some points:

1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.

2. Many orgs have a poorly managed culture around disagreements on technical design and some folks just don't want to put up with that kind of friction when the difference between using approach A or B is real, but not going to topple the project either way so why waste that energy fighting that kind of battle?

> Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.

Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."

You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave!

If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.

Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.

Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.