Specifying and applying broad changes to a program
- by Victor Nicollet
How do you handle incomplete feature requests, when the ones asking for the feature cannot possibly write a complete request?
Consider an imaginary situation. You are a tech lead working on a piece of software that revolves around managing profiles (maybe they're contacts in a CRM-type application, or employees in an HR application), with many operations being directly or indirectly performed on those profiles — edit fields, add comments, attach documents, send e-mail...
The higher-ups decide that a lock functionality should be added whereby a profile can be locked to prevent anyone else from doing any operations on it until it's unlocked — this feature would be used by security agents to prevent anyone from touching a profile pending a security audit.
Obviously, such a feature interacts with many other existing features related to profiles. For example:
Can one add a comment to a locked profile?
Can one see e-mails that were sent by the system to the owner of a locked profile?
Can one see who recently edited a locked profile?
If an e-mail was in the process of being sent when the lock happened, is the e-mail sending canceled, delayed or performed as if nothing happened?
If I just changed a profile and click the "cancel" link on the confirmation, does the lock prevent the cancel or does it still go through?
In all of these cases, how do I tell the user that a lock is in place?
Depending on the software, there could be hundreds of such interactions, and each interaction requires a decision — is the lock going to apply and if it does, how will it be displayed to the user? And the higher-ups asking for the feature probably only see a small fraction of these, so you will probably have a lot of questions coming up while you are working on the feature.
How would you and your team handle this?
Would you expect the higher-ups to come up with a complete description of all cases where the lock should apply (and how), and treat all other cases as if the lock did not exist?
Would you try to determine all potential interactions based on existing specifications and code, list them and ask the higher-ups to make a decision on all those where the decision is not obvious?
Would you just start working and ask questions as they come up?
Would you try to change their minds and settle on a more easily described feature with similar effects?
The information about existing features is, as I understand it, in the code — how do you bridge the gap between the decision-makers and that information they cannot access?
