A specification to specify specifications within specifications
Anyone who has worked in a project involving writing some software would have come across specifications of some kind - those holy documents written by the project elite that are a pain both to implement as well as to maintain and serve nothing more than as a hurdle to getting to a working product.
Often spec documents either derive from another or many such documents build, by way of cross-reference, a connected specification which soon creates a need for another document to describe the relationship between these docs... which, of course, has to be kept up-to-date not only whenever any specification is updated but also when there are relationship updates or when new nodes come up etc.
Soon anyone entering the project has to pass through this wall made of the interconnected web of specs only to understand soon enough that the product he/she is working on is quite different from what the specifications are dreaming about.
Often times, to the authors the specs are sacrosanct and reality comes second. Many a project team suffers a sorry fate getting strangled at the hands of the spec they themselves created.
Yet there is still so much obsession in creating and maintaining these documents throughout the project lifecycle, well beyond their usefulness (if at all there was one to begin with).
I quite vividly remember the irony I felt when one of the first projects I started working on closed after a team of about 80 of us (yes, eighty !) toiled on it for a long time. In fact I had only joined the team 2 months ago but the project itself had been on for more than a year. There was a high-priority meeting scheduled one afternoon and the invitation specified no agenda. As I came out of that meeting with the knowledge of the project having been sealed, the irony of what I spent the first half of the day stuck me... I had just spent prior to lunch close to 3hrs discussing and noting down with the owner of the functional spec for the project, the changes that will be made to it to match with the reality of my module - and we had good reasons to make each one of them.
That is probably why when I read this article- I totally resonated with the idea. I found myself in agreement with almost everything on that page (I find myself in agreement with almost everything in the book anyway and I think "Getting Real" is a must-read for anyone in SW development).
The clincher was the quote from Linus, which I reproduce here.
A bite-size doze of common-sense like the article above can really make a lousy day into something worth living for and goes a long way in helping me keep my sanity :-).
As SW engineering matures as a discipline, the teenage infatuations of watertight specifications and obsessive process quality addictions are beginning to look like the cool "must-have" gizmos that seem absolute essential to the adolescent identity which later are the stuff of bar-time jokes and bashful nostalgia.
Often spec documents either derive from another or many such documents build, by way of cross-reference, a connected specification which soon creates a need for another document to describe the relationship between these docs... which, of course, has to be kept up-to-date not only whenever any specification is updated but also when there are relationship updates or when new nodes come up etc.
Soon anyone entering the project has to pass through this wall made of the interconnected web of specs only to understand soon enough that the product he/she is working on is quite different from what the specifications are dreaming about.
Often times, to the authors the specs are sacrosanct and reality comes second. Many a project team suffers a sorry fate getting strangled at the hands of the spec they themselves created.
Yet there is still so much obsession in creating and maintaining these documents throughout the project lifecycle, well beyond their usefulness (if at all there was one to begin with).
I quite vividly remember the irony I felt when one of the first projects I started working on closed after a team of about 80 of us (yes, eighty !) toiled on it for a long time. In fact I had only joined the team 2 months ago but the project itself had been on for more than a year. There was a high-priority meeting scheduled one afternoon and the invitation specified no agenda. As I came out of that meeting with the knowledge of the project having been sealed, the irony of what I spent the first half of the day stuck me... I had just spent prior to lunch close to 3hrs discussing and noting down with the owner of the functional spec for the project, the changes that will be made to it to match with the reality of my module - and we had good reasons to make each one of them.
That is probably why when I read this article- I totally resonated with the idea. I found myself in agreement with almost everything on that page (I find myself in agreement with almost everything in the book anyway and I think "Getting Real" is a must-read for anyone in SW development).
The clincher was the quote from Linus, which I reproduce here.
A "spec" is close to useless. I have never seen a spec that was both big enough to be useful and accurate.
And I have seen lots of total crap work that was based on specs. It's the single worst way to write software, because it by definition means that the software was written to match theory, not reality.
—Linus Torvalds, creator of Linux (from: Linux: Linus On Specifications)
A bite-size doze of common-sense like the article above can really make a lousy day into something worth living for and goes a long way in helping me keep my sanity :-).
As SW engineering matures as a discipline, the teenage infatuations of watertight specifications and obsessive process quality addictions are beginning to look like the cool "must-have" gizmos that seem absolute essential to the adolescent identity which later are the stuff of bar-time jokes and bashful nostalgia.
How does an open-source project's spec look like ?
ReplyDelete