Friday, April 03, 2009

What Specs are Good For

I'm reading Making Things Happen by Scott Berkun. It talks about how to best manage software projects. I'm a big fan of writing and iterating specs because I believe that thinking about building something is way cheaper than actually building it. I liked this list from the book:

"Here's a list of the importance things specs do for a project:
  1. Describe effectively the functionality of what will be built
  2. Help designers clarify decisions by forcing them to be specific
  3. Allow the review, questioning, and discussion of detailed plans before full implementation begins
  4. Communicate information from one to many
  5. Create a team-wide point of reference for plans
  6. Provide a natural milestone to focus the team
  7. Create insurance against author(s) getting hit by a bus
  8. Accelerate, improve, and increase the frequency of healthy discussions
  9. Give leaders an opportunity to give feedback and set the quality bar
  10. Add sanity and confidence to the team
Things specs cannot or should not do:
  1. Eliminate all discussions between team members
  2. Prove to the team how smart the author is
  3. Prove how important a feature is
  4. Convert people to a philosophical point of view
  5. Be a playground for the author's Visio or UML skills
In my professional experience so far, projects that did not have a spec written before writing the majority of production code have consistently failed, were late, or didn't meet quality standards. "Just hacking it up" almost never works for complex projects. Especially junior developers often lack the discipline to write a spec, even though they would benefit from it the most. Maybe this list will nudge some people in the right direction

2 comments:

Anonymous said...

The big problem with this stuff is usually everyone wants the spec to be whatever it is they're used to, including their being no spec at all, instead of saying "hey. we need to work together. what is going to work for us 5 people?".

So I don't think having specs or not having specs is as important as the team talking to each other about how to work together in the best way, and to get the best results.

I've yet to see a team of 5 or more people have a discussion about achieving "the best results" without agreeing to writing their big decisions down and updating them as they change. At least for awhile :)

- Scott

Gabor said...

Thanks, Scott - I'm amazed that you've responded to this - after all you wrote "The Book" :-)

At reMail, we definitely have those discussions of what works best, but the problem often is that engineers start implementing what they saw was the consensus from that discussion, without necessarily having talked through the repercussions of that design.

Also, we have a pretty standardized format for Design Docs that we use, which has worked really well so far. Maybe I'll post that here one day.