My main project at work has been developing an authentication plugin implementing the SAML2 protocol. For the last three months I’ve also been developing a web-based issue tracking system, with the goal of unifying our internal workflow as well as improve communication on user reported issues with our customers. In my last post, The Mythical Man-Month, I quoted the following sentence which resonated with my experience from these (and previous) projects.
Both the actual need and the user’s perception of that need will change as programs are built, tested and used.
The most common realization of these changing needs is probably the feature creep. A person who has two problems, A and B, and get access to a system that solves A would obviously like it to also handle B. Lets call this the “one system fallacy”.
This is a belief that there should be one system to rule them all, so to speak, though this rarely leads to a good end result. What one usually would like, however, is multiple applications that complement and integrate with each other. For example, I’m sure someone, sometime thought that adding a word processor to Gmail would be great. It wouldn’t have been. A much smarter move was building a separate application for the word processor, but which shares the same login as the one I use for my e-mail.
Another problem is that often times people are not really stating their problems, but rather their ideas of solutions to problems. In one of my courses at Chalmers I heard an anecdote about the development of a new American fighter jet (I’m paraphrasing, but if anyone knows the source, please share). The company that got the order received a requirement stating that the plane should have a top speed of mach 5. This wasn’t feasible so the team tried to locate the source of the requirement. After much searching, it turns out it came from the pilots. When asked why, they said they needed to be able to outrun missiles fired from a MiG.
In other words, the problem was not that the plane was too slow, the problem was that they would get shot down by the enemy. A much more practical solution was to improve the electronic countermeasures. In the sphere of web development, the requirements we get can be something along the lines of changing the color of the links or adding file uploads to our comments. Either way, it is important to understand what the problem is.
Once you understand the problem, you need to understand how critical a solution is. This is sometimes obvious. Implementing a Tetris easter egg would probably fall on the opposite side of the scale from a bug causing the system to crash whenever a user logs on. Other times it is less clear, but I’ve found that important things tend to pop up multiple times from multiple sources. If you’re unsure, give it a lower priority and wait.
When communicating your the plan regarding the suggestion to the user: underpromise and overdeliver. Not everyone agrees with this tactic, but dealing with changing requirements means you are unable to promise much even for seemingly simple suggestions. Once you do implement something, let them know and they’ll be grateful (and most likely be ready with a few more suggestions).
I’ve heard lists are a great way to get readers, though I couldn’t bring myself to use that selling point in the title. Instead, lets half-ass it and summarize the steps that should be taken when receiving a suggestion.
Listen. Don’t be an asshole, hear your user out.
Identify the real problem. At first the suggestion might not make sense, but it may very well lead to an important change or addition once you grasp the underlying issue.
Prioritize. I rarely say no to suggestions, but I’m also careful to point out when something is technically challenging or might be out of scope. Underpromise, overdeliver.
Have I missed something? Am I wrong? What are your experiences with dealing with changing requirements in a light-weight development setting?