He’s talking about a large project (which may take longer) being split in several small projects where each only spans over a few weeks. But even then, even for a one-man project, a formal spec about *what* you plan to do is useful.

I agree that it’s absolutely nuts to write down a 20 page document which takes you a whole week to write down only to end up with a notepad clone with a scrollbar on both sides.

But having an idea written down (even on a small post-it note) helps me to keep focussed on what’s essential. When all you want to do is a notepad clone, it’s silly to implement buttons to make text bold/italic and so on. These would not be “functionally” required. But along the line of coding I often have the thought: “Would it not be nice/cool/great to………”. This though is distracting and if not careful you end up implementing something that’s not necessary (not immediately anyway). In addition, getting side-tracked risks other part of the project being “left behind” or forgotten. Having a clear goal in front of your eyes helps you to get back on track. At least that’s the case for me. I get easily distracted by cool and shiny new things.

What is more, having a goal specified helps me to see the Big Picture a lot better. This in turn helps to make design decisions along the lines.

On the bottom line, getting distracted is clearly my personal flaw. Having a formal spec helps me to stay on the right track. And I’m certain that there are others having the exact same problem. For people like us, formal specs are a damn cool thing!

On the top of my head I could go on stating the abundance of advantages you can have from *well written* (!!!) specs. But on the other side, if the spec is written by someone without the necessary domain knowledge and/or insights in the development process you’re in for a real treat, and I hope for everyone’s sake that they will never have cross high bridges when working in such a situation. Because you would most certainly want to see how it would look like to see the bridge moving away from you at fast speeds while watching it from below

The problem is, it’s not always easy to recognize a poorly written spec (although often it is). If it’s poorly written, throw it out of the window as soon as possible!

Anyway….. I’m rambling on again, and I lost my train of thought as I was just interrupted here in the office…. :/

I’m sure this is a brilliant topic for some heated discussions, and it certainly is good fun to find valid arguments for and against specs.

Damn…. where’s that bloody train of thought gone….??? I’ll just stop babbling here and now!

he’s talking about a small company with 10 employees and projects which never take more than a few weeks.

in most cases, for projects like that you don’t need specs. i agree maybe if you have a large projects with about 12-20 people involved and the project’s about to stretch over 6 or 12 months. but for 6-week projects with a 6 headed developer team you don’t need specs. but that’s just my opinion.

But apart from that it’s been interesting. I’m curious to see what’s there to see in the last 30mins….