the best way to write a software specification

i hired in as a programmer, but after a little over a year, when i became full-time, that changed. they said i would be programming half the time, and splitting the rest of my time between writing software specifications and testing. what really happened was that i started alternating between full time testing and full time spec writing.

spec writing isn't hard, but it's time-consuming if you're going to do it right. for the longest time, i was handed a rough outline and expected to flesh it out into something comprehensive. the more time i spent, the better things ended up, but they were still lacking.

i started running things by jim, my supervisor, before passing them back to the programming department. he would think of things i had missed and that would trigger more ideas on my part, and the quality skyrocketed. we decided to look into it further, see what other companies did. we knew immediately that our company would never go for it.

see, other companies get nearly everyone involved. there are programmers, testers, marketers, support people, customers and pretty much anyone else with a pulse. they spend as much time as is necessary to hammer the thing to near perfection before a single line of code is written. the time investment is worth it, though, because the cost of a single bug getting to a customer is so high that anything caught on the front side is a savings, period.

we pitched this idea to the people who mattered, and were repeatedly shot down. we were told it was inefficient. we were told that it was impossible to get the proposed group together on a regular basis (though later that day, an even bigger impromptu meeting was called ).

specs had to go on hold for a while as the testing department got overwhelmed. at some point, the tech support guy who likes to get his hands in everything (until he gets bored with it) started writing specs. they were atrocious, so jim and i stepped in and got ourselves involved.

they still wouldn't go for the meeting. they thought the ideal way to go would be for each spec to pass from person to person, each doing their part, with the end goal being an awesome spec. if someone had a question or thought something was wrong, they would pass the spec backwards so the appropriate person could make the changes. there are a total of (i think) ten steps before a programmer starts working on it.

well, we started to notice that each spec takes 10-20 hours, all told, and they still come out with huge holes in them. finally, someone said this:

'since these things are taking so long and they're still lacking in some ways, we should maybe just have a meeting after the initial designs are done.'

hahahahahaha