Getting stuff done
When a developer is put on a project without clear requirements, and without someone from whom to gather requirements, they’re being put into a very difficult position. If they just make arbitrary decisions about the design and start implementing, it’s likely there will be a lot of wasted effort, both through extra, unneeded things being implementing, and through the wrong things being implemented that consequently have to be done over. So that they don’t have to do over a bunch of work before the product is ready, they stop before developing and try to plan it out. But they don’t have the information to be able to plan anything, so they try to talk to other people to find it out, and they end up waiting around while the others, who might have a meager idea of the requirements, get back to them. In the meantime, the process is repeated on some other subissue, and because humans can only do so many things at once, the poor project developer ends up forgetting about the first issue.
So what’s the solution? Those who know the requirements should be very available to answer all these questions right when they come up. In the absence of such people, can individual “initiative” make up for this? This “initiative” will lead to a lot more work being done, but a relatively small portion of that work will meet the requirements. So it’s not clear whether the extra work is worthwhile. It would depend on the relative value of the time of the various participants, and of the nature of the decision to be made about requirements. (If it’s a relatively minor point, it’s definitely not worth stopping work over). If the people that know the requirements don’t have time to communicate them thoroughly to the developers when they first start development, that doesn’t change the fact that they’ll have to communicate them eventually. So there’s really no point in it not being done immediately.
So what if it can’t be done anyway? What if the people who know the requirements are simply inaccessible most of the time, for some reason? What should be the top priority for our abandoned developer when he has run out of clear directions? There are a few choices here. He could choose another project or issue within the project whose requirements he has better access to. He could attempt to do some more generic version of code that meets the reqeirement that can be specialized later. (Which is often overwriting the software.) He could simply pick arbitrary directions to go with the code.
Any three of these options could be the correct choice in a given situation. If the project has plenty of room before its deadline, then working on another project of slightly lower priority whose requirements are already known is probably the best choice until the requirements for the first project can be clarified. The developer should be sure to write down all of his current state so that when he comes back to the project, or when someone with requirements knowledge becomes available, work can be resumed without wasted additional effort to recover a working memory of all the issues that were being ruminated upon before.
If the project needs to be done soon, however, and the requirement ambiguity can’t be handled simply by doing generic code or adding configuration options–deferring the decision but not holding up development–then the developer is faced with the harsh reality of having to write code inefficiently, because the most efficient use of his time would still leave the project behind a deadline, even if other projects were able to advance more quickly. (And let’s face it. Those “other projects” are really easter eggs, eh?)
It all really comes down to the exact nature of the ambiguity. If taking the wrong direction would mean a complete waste of time–even considering that writing the code would make it easier to write similar code in the future, even from scratch–then the project has to be more or less stalled. But if the decision is something that might not really matter anyway, or even if it’s something that the customer won’t get to mad about when they discover how wrong it is, then an arbitrary choice might not be so terrible.
But god damn, I hate arbitrary choices. Maybe I just need to get over it.
I should think about how this applies in the case where the project is a hobby and the person who knows the requirements is also the developer, but is unable to find the energy to discover the requirements.
