This guy’s bitter. Why specs matter: most developers are morons, and the rest are assholes. (modded down, yo) Go read it because I’m not going to summarize it here for you.
Done? Good, because if you didn’t read it, none of what I have to offer will make any sense.
Apparently, the author is pissed off because nobody he work(ed/s) with has the ability to see the “big picture” behind their particular software project, and they don’t follow The Rules. I can empathize; I’ve bitched about it before. But, reading it from someone else’s point of view makes me realize what a whiny little bastard I washe isanyone who upmodded the article is being.
I can’t argue whether or not every single developer he’s ever met falls into his snitty little categories. Of course, if you’re not part of the solution, you’re part of the problem.
A spec is just a spec. It’s a cut-and-dry document that says “we need this” or “the product should do that”. It might even say “this parameter is an 8-bit unsigned integer”. But, it most likely doesn’t explain how the goals it describes are actually met. How is anybody going to figure that out if they only have the spec to work from?
Work together (read: communicate) and constantly ask, “How is this supposed to work?”.
Seriously, that’s it.
Now, I’m not going to say that our company is the model of software development by which all other companies should be judged; we’re far from that. But, we constantly communicate about the project. In between the somewhat-regularly-scheduled product meetings, we actually walk to each others’ offices, sit down and talk about shit. That’s not to say that every coder in the building takes the initiative to talk to everyone else, or that some of the Nerd Herd even have the ability to see the “big picture”.
What we do have, however, are just enough “in-betweeners” that fill in the gaps between the head-down, code-to-spec keyboard jockeys and the starry-eyed, anything-is-possible spec writers and dreamers. I’m an in-betweener. The task-oriented coders know full well that I’ll go in and dick with their code if I don’t think it looks or behaves properly for the product. Their code might be to spec, but it’s not “finished”. Alternately, I know full well that the hardcore guys will go in and dick with my code to optimize it or to use the latest neato Python doohickey that magically reduces ten lines of my code down to one. My to-spec code might work, but it’s not “finished” either.
It’s the in-betweeners’ job to talk to the project engineer whose customers will be using the product, and—in all likelyhood—will be using it himself. “How is this supposed to work?” He’ll tell you what he needs the product to do in specific terms regarding vague ideas e.g., “I need a web interface to change network settings on a machine”, or “I need to be able to write certain configuration parameters to a particular file over the network”.
It’s also the in-betweeners’ job to relay the user requirements to the software developers, and discuss in specific terms how to go about implementing them. “This is how it’s supposed to work, now how are we going to make it work?”. “We’ll need to come up with a spec for that config file”, or “will I need to restart the daemon after writing those network settings?”. And so on.
Then back to the dreamers. “This is what we have. What do you think? Does it fulfill your requirements?” Then back to the nerds. “We also need to monitor the status of the frapinator daemon.” Et cetera. Back-and-forth, constant communication.
And, sometimes, it’s the in-betweeners’ job to stitch together the user interface with the back-end code… at the right stage. It’s much easier to beautify a butt-ugly interface to properly functioning code (per the spec) than it is to take a pretty—yet useless—interface and make it work on the back end. It’s their job to know that and help steer product development.
“Tell you what, give me hooks or simple calls in your superman code, then I’ll make the interface use them, deal?”
Quit bitching, quit placing blame, quit being Teflon… and talk with your co-workers. Step up and be a mediator between the morons and assholes.
Of course, none of this will work if you’ve staffed your software development department with a bunch of jerks who are looking to do the minimum amount of work to score that paycheck every month, but without taking on any real responsibility or accountability. Nobody should hire those pricks, but that’s another rant altogether.