A few weeks back, I asked our recruiter to post a developer job on the Stack Overflow job site. I had seen the Joel Test before, but it was the first time I tried to figure out how well we were doing at msnbc.com. I was puzzled by #7:
7. Do you have a spec?
Bear in mind that I began my career as a Program Manager at Microsoft. I had been schooled in a rich tradition of spec writing. And while a spec has its place, it often leads software development efforts astray.
Consider a spec that reads as follows:
Port existing feature X from the legacy system to the new system
Specs like that should be shot on the spot. But I digress. We have a legacy system and a new system. After the new system was put into production, I started to see some specs like the one above. Here's the true story of how one of those efforts went (details have been altered to protect the innocent)
After a couple of weeks worth of work, I participated in a review of the project to date. Things had gotten complicated really fast. At the heart of the complexity was the need to do a many-to-many mapping between settings and sections. When I asked how frequently marketing used that feature in the legacy system, the response was “We don’t think they’ve ever used it, BUT you *can* do it in the legacy system, so we need to do it in the new system as well.”
This was troubling to say the least. I had a brief vision play out in my mind…. it would be like if I asked someone to install a trampoline in the northwest corner of my yard and it took the contractor 12 months and $300,000 to do it. I would ask the contractor what on earth happened. He’d reply that he needed to re-grade my entire lot and the lot of my 2 neighbors in order to make a nice big flat spot for the trampoline. He adds that putting the trampoline in the north east corner of my lot would have taken 2 hours and cost $500, but he was in the business of giving the customer what he wanted.
I volunteered to talk to the marketing stakeholders about simplifying the features. I geared up for a lengthy conversation with the marketing folks to explain why simplifying the requirements would be a good thing. Customers are hard to please, right?
The phone call with Joe went something like this:
Bryan: Joe, can we talk about the requirements for the port of feature X?
Bryan: I’d like to propose we simplify things to expedite delivery. Would it be OK if ditch the many-to-many mapping in favor of a 1:1 mapping between sections and settings? I think we’ll get done 3 times as fast.
Joe: That would be great!
Bryan: Fantastic. Talk to you later
Although the aforementioned conversation is a simplification, it doesn’t distort what actually happened in any way. Turns out the stakeholders wanted something simple that worked now far more than they wanted something complex that worked in the future. I've never seen a spec template with a section for stuff like that.
There are many morals to the story. I'll focus on just two.
1. Specs can hurt you
2. It's your duty to simplify requirements
How might specs actually hurt you?
There are two ways demonstrated in the story above:
1. The development team begins to believe that the original spec is somehow holy and immutable. Their job is to meet the spec, not to deliver value to the customer
2. It can end the conversation between product users and product creators. Both groups will suffer before the product is finished (IF it is ever finished).
Why should I simplify requirements?
1. Stakeholders have a hard time giving feedback on a document. Most stakeholders give much better feedback when using the actual software system as opposed to commenting on a Word document. As developers, we need to put that system in their hands as soon as possible. Simple requirements make this possible.
2. Stakeholders tend to value a less than perfect system that helps them today than a perfect system which *may* (or may not) be done 6 months from now.
So do we have specs at msnbc.com? It depends on what you mean. For the products I've worked on in the last 2 years, I've produced and consumed precious little formal specifications. On the other hand, we've had back logs with work items that get defined in face to face conversations as the feature gets built.