I agree, but I think this is one of these topics where company structure, the domain of the project and the mindset of participating developers all play into wh

I agree, but I think this is one of these topics where company structure, the domain of the project and the mindset of participating developers all play into what "what-if-driven" means. 1. Sure, never add code and complexity for features that were never requested. Don't implement "anticipated requirements" 2. Sometimes, clients or stakeholders need to be reminded of a bigger picture to make clear that the design decisions they suggest would cause hard-to-maintain code, security problems or bad UX, proposing to modify or clarify the requirements. 3. I'll try to add some (wildly different) examples to 2: - This form needs no server-side validation as long as it can only be submitted with a valid login. - This form does not need a save button. Let's just save on input / field change (not regarding context and field types, or integrity constraints, or UX in edge cases, or complexity) - We already have this similar-looking UI element, so we can just reuse and adapt it - Can't we just let the customer define validation rules in an excel sheet using a very specific syntax that we define - Please use this combobox/multiselect design and implement it perfectly. It's beautiful. (Design has no indication of selected values while closed) - No user will ever click this button so fast, let's ignore that case There are some bogus examples in there where most developers would seek dialogue to improve on the requirements, or which wouldn't occur given a healthy PM and development culture. Or would they?