Holy Requirements
Assignments in college come with specific parameters for good grades. If the project assigned doesn't have some kind of guidance onto how it will be graded, it's impossible to know when you're finished.
But what if your boss came to you and said we need to build a system that does the following things:
· Hosts a website with a text form where any user can start a text entry.
· Persists the text on submit.
· Allows any user to restore and edit that text.
What are the questions that need to be answered before you can start coding? How would you know when you're finished or if you've done a good job?
Carefully note if your first instinct was to just throw together a webpage and SQL server and be done.
It’s not an easy problem by any means and a simple submit and persist form won’t work. The third bullet makes this impossible. If any user can restore and edit the text:
· What happens when two or more users edit and submit the text?
· Is it “thunderdome” and the person that submits last overwrites anything else?
· Should it warn the users that another user has edited?
· Should it merge the changes?
· Should it provide an experience to help you merge the changes?
The typical answer from the boss figure or customer is “Yes.” But none of these things were defined in the original list and one of them (or one you haven’t thought of) has to be the answer.
Think about all possible paths before you start coding. The devil is in the details, in the cross team dependencies, in the customer using the product unexpectedly, in the scalability and so on and so on.
Non Goals
A practice I’ve seen here at Microsoft is to state what your non-goals are. In our problem above, a non-goal could be to not provide a way for people to merge input. This is a good thing because it explicitly puts an upper limit on what you plan to do. The non-goal has to be acceptable from the customer point of view (“non-goal: ship the product”) and has to be something meaningful and actually constrain your design (“non-goal: ship the product before DNF comes out”).
With a non-goal, you can fire back at someone who suggests you implement features Foo and Bar and Kitchen Sink. Because these features are stated in your non-goal, you can say you’ve already thought about them and decided not to do them. Most importantly it prevents feature creep and remember: shipping is a feature.
