Functional specs matterPosted: March 15, 2006
OK, I’ve decided to take the opposite extreme to the 37signals crew because extremes seem to cause people to pay attention. So, here’s my extreme statement:
Functional specs matter. If you don’t use them, the probability of building anything well and building it on time is next to zero.
Now Jason Fried seems to have a different opinion. He basically says:
Don’t write a functional specifications document. Why? Well, there’s nothing functional about a functional specifications document…. Functional specifications documents lead to an illusion of agreement…. Functional specifications document are “yes documents.” They’re political. They’re all about getting to “yes” … Functional specs are often appeasement documents. They’re about making people feel involved….
He’s got lots more to say but that’s it in a nut shell. So, how does Jason propose to build software instead?
We suggest building the interface first and using the actual screens as the functional spec. There are times, however, when the interface doesn’t provide all the information required for the programmer to hook it up. Designers should always present the programmer with the multiple states of an interface element so the programmer understands what to display when this or that happens.
Hmm, giving the programmer extra information so she understands exactly what a mockup is communicating. That sounds like a functional spec to me. In another post Jason describes some work he was doing on the Files section of Basecamp:
Step one: Make a mental list of the must-haves. You have to know what you’re designing. I looked at the current ‘Upload a file’ screen and decided these things must stay:
- The ‘Choose file’ widget
- An optional description
- The privacy checkbox
- Email notification
Step two: Sketch a layout on paper. The sketch includes the must-haves…
Step three: Make the screen. Thinking and sketching took me 10 minutes. Creating the real screen and updating the code can take two or three hours.
Jason likes to keep things very light. Outline what you want to do mentally or jot it down quickly, then make a quick sketch. If the sketch looks good (presumably he floats it past a few folks), migrate the sketch to a real screenshot, with story as necessary, so a programmer knows what to build.
This is where I become confused in the “don’t write functional specs” mantra I continually see from 37signals (yet another today). The purpose of a functional spec is to decide what you want to build before you build it. Why do you do it? To save unnecessary thrash during actual building. 37signals absolutely does this. So, in my mind they are building functional specs.
So, functional specs do matter. They even matter to functional spec haters. 🙂 But if they’re so useful, why are there haters? As Jason correctly points out, lots of company have sole positions that write specs and toss it over the fence to developers to build. In some cases these spec writers rarely interact with anyone before writing the spec. This is really a poor way to build software because you’re not leveraging the unique perspectives and talents of everyone on your team or your customers (aka Wisdom of the Crowds).
The best software in my experience is built by a small group. Also, faster cycles (for most projects) are better than longer. The quicker to market you are, the faster you’ll know whether your idea works, needs more iterations or simply sucks and should be removed.
The points of wisdom I take away from Jason and company is keeping your documentation as light as possible, keeping cycles short and hearing your customers. His catch phrase of “Getting Real” is perfect in this regard. But “Don’t build functional specs,” while a good attention grabber may end up leading small, new development shops in the wrong direction. Given 37signals really is writing functional specs, this advise is really misguided in my opinion.
The write message for small developers is “Functional specs matter.” Know what you want to build before you build it.