As software developers, one of the best things we can do for our clients (internal or external) is to restrain from bombarding them with questions about trivial and easy-to-change aspects of their requirements.
When I find myself in doubt about how some aspect of the software I’m developing should work, I try to identify if the requirement is “bikesheddable” before stopping my progress to reach out to the client.
For example, the client has a requirement for a feature like “when an administrator grants access to a new user, the user should be notified by email.” I’ve seen developers (typically more junior) block their progress on a feature like this until the client gets back to them with a definitive answer on what title to use for the email.
I define a question about the requirements of software to be bikesheddable if it is…
- Trivial
- Likely to generate back-and-forth and delays
- Easy to change later
If it’s bikesheddable, pick a sane default and continue on with the feature. When the client sees the feature deployed, they are of course most likely not even going to notice the choice you made for the aforementioned bikesheddable thing, but if it happens to matter, by way of #3 above, you can easily change it later.
Get the broad strokes right in v1, and the fine details in v2 and beyond.
