Specification

Today I was in a meeting with... oh wait, they might be reading this someday.

Start again. Uhhh... yesterday, a good friend of mine, who just happens to look like me, and who, purely by coincidence, possesses lots of characteristics not dissimilar to the ones possessed by yours truly, might I mention, for example, modesty, charisma and almost a superhuman quality in the highly esteemed general area of... oh wait, I digress. (Heh heh. The suckers won't be able to prove anything now with this legalese in place.)

Anyway. The friend, who works in an unnamed company, that is not actually in the software business, but whose business revolves around a huge, custom-built software application, was in a meeting with the business people. Now, this company, as unnamed as it is, is still learning a thing or two about software development, so they're not actually "mature" as defined by the CMMI model. In fact, they might still be on the scarcely mentioned "using Etch-A-Sketch for a laptop & occasional cannibalism at status meetings" level. In this company, the functional specification for the custom software is not written by professional functional specification writers. Instead it's written by the business people. People who aren't trained to write specifications.

So, anyway, some coder was in a meeting with some business people who write the specs. He asked the business people a question about the software, about how a certain detail should be implemented and if they could provide a document listing all the ways how a certain set of properties should be determined in any given situation. It was a quite a complicated piece of functionality, and the business guy who answered did it by saying "well, I don't know how it should go".

Now, let's pause for a second. Then let's think of the ramifications of that answer. We're implementing software. We're doing it because we need to have a part of the business logic of the company automated, to be handled by computers and software. We need to have it automated mostly because it is not feasible anymore to have certain things, like calculating lots and lots of data, done by humans. Otherwise the company could not exist in the present day competition in the specific business segment. So, what do we actually make the software do? These days, software can do amazing things. Things you wouldn't have dreamed about just 10 years ago. Just take a look at some of the products provided, free, by Google. What do we implement with all the cool technology we have now?

We implement the things the business experts tell us to do. They give us the specifications and then we implement them. Then, the testers verify that the software functions as specified. Then the, users learn to use the functionality by reading the manual, which is derived from the spec. Then, they actually start to use the system in the production environment.

Now, what happens, if the spec isn't there, or isn't detailed enough, or isn't written down in a clear format? What happens is that there is a vague assumption, or in fact, a huge number of vague assumptions, floating around the project about whatever the project is supposed to implement. The coders will interpret it each in their own individual way, the testers will interpret everything individually as well and the users will complain a lot, mess up whatever it is possible to mess up in the application and even stop using the application and continue to rub two pieces of wood together in order to light a fire, metaphorically speaking, if they can.

If there isn't a detailed spec, the coder can write just about anything and it will all be equally good or bad. If the spec says "build a messaging system", the system could spit random insults to the user and the app would still be perfect according to the requirements.

If the spec isn't there, the testers will make a lot of assumptions of how the app should work, and issue bugs of anything they don't like. A lot of arguing will ensue about whether or not the functionality is correct. A huge number of man/woman hours will be wasted.

If the spec isn't there, how will you construct a building? "Well, I suppose it's gotta have some floors? 3 or 20? Anybody couldn't want more than 45. And some windows, you gotta have those. And a radiator to keep it warm, or should we have two? Never mind, we'll make it up as we go." I tell you, software is a lot more complex than a building. And yet, software is being built without decent planning.

Now, let's get back to the innocent "I don't know" uttered by the guy who should know. In my perspective, he's the guy who should know. Everything. And if he actually doesn't know something, he should find it out. And if this isn't possible, he should still write the spec, with the best assumption, and possibly with a comment saying that there is some uncertainty involving the subject and detailing everything that is known about it at the moment. Yeah, I'm a Nazi. But it's cute when I do it! And we can change it later, when we know more about it. But it's still vital to document everything about the known, and unknown issues.

In a software project involving about 3 people or more, you've got to have a decent spec. If the spec is not written & pictured, everyone involved will picture their own mental model. You picture a balloon, that guy sees a pyramid, that jerk over there is imagining a train speeding into a tunnel, I see a monkey with five asses. The results won't be pretty if the goal is not synchronized, and everything would be a lot cheaper & faster if you knew what you're trying to build from the beginning. I tell you, the spec is just as important as the code.