4 ms·

Maybe the author doesn’t realize this but “what-if-driven development” is one of the worst programming advice one can give. The problem is that it gets interpr

by d--b 3y ago

Maybe the author doesn’t realize this but “what-if-driven development” is one of the worst programming advice one can give. The problem is that it gets interpreted as “I’ve been asked xxx but what if what they really want is yyy”. And this leads to missed requirements, premature optimization, and all other evils.

kuratkull 3y ago
“I’ve been asked xxx but what if what they really want is yyy” - in my experience they usually want yyy, xxx is just how they managed to write it down using existing terminology/environment.
moritzwarhier 3y ago
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?

by d--b 3y ago

kuratkull 3y ago

“I’ve been asked xxx but what if what they really want is yyy” - in my experience they usually want yyy, xxx is just how they managed to write it down using existing terminology/environment.

moritzwarhier 3y ago

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?