The importance of specs
Posted by admin on May 7th, 2007I’ve recently finished reading a book called Joel on Software, by Joel Spolsky. Despite the title, the book is not about hardcore software coding. In fact, it doesn’t teach people very much about code. Rather, Joel talks extensively about managing a software project, and the lessons learned from this book can be applied to any kind of project, not just software.
One of the most valuable things I’ve learned is the importance of specs. As a college student I never wrote any specs, at least not on paper. I would “figure it out” all in my head, and start to code like a little tiger in the wind for a few hours, until I realized that this Airplane class I had so thoroughly designed is actually missing a few key components. Now I have to stop and modify it before I can go on, and because I modified the Airplane class, now I have to modify the Flight class and the FlightSchedule class. Great. That only took about 3 hours.
Here’s what Joel has to say about NOT writing specs:
Why won’t people write specs? People claim that it’s because they’re saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.
…and here’s what he has to say about writing specs:
The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec — describing how the program works in minute detail — will force you to actually design the program.
Since I’ve joined IBG I have learned that specs are invaluable. Knowing what you’re going to write before you write it is 3/4 of the battle, and it will cut down your production time, as well as bugs.
So from now on, whenever you have a project, be it software, hardware, or anything else, write specs first. KNOW what you have to do before you do it.
For more info on what a spec is and how to write a spec, go on to Joel’s article.
