Linus Torvalds Outburst Sparks Fierce Debate: Does Open Source ...
|
|
|
Comments (2)
I like to use software specs just as general guidelines and don't consider them to be written in stone, they can be especially usefull in a team so that everyones knows the general goal even though the goalposts will be moving all over the pitch and by the end of the game you can have a good laugh at how bad at referreeing the specs were.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post

I suspect they suck rocks in other areas, too, but get ironed out during the prototype phase prior to manufacturing.
That's why processes aping other engineering and manufacturing protocols fit software so poorly. There is no manufacturing phase in software. Burning DVDs/CDs and putting them in boxes doesn't count -- it's an undifferentiated act more akin to shipping products than making them.
Spending too much time and trouble up front in software design wastes the learning potential of the prototyping phase, takes undue time that could better be spent on making better software, and reduces opportunities for end-user feedback and its potential for "No, I think you misunderstood - That's really not what I was looking for."
This is not to say that some level of specs -- data requirements and interface design -- are unimportant, just that, generally speaking, software specs suck. If only spec writers would study Bauhaus and learn what "less is more" is all about.