Hey Specsy

Note: This Post is partly a repeat of my previous post, SDLC. Specs are the most important thing which a product team could come across, hence I have devoted this post to it.

Lets take the simple example where you plan to build a house. The whole process will require a lot of brainstorming before you lay the first brick. First, you look at the ideal location. Once you have that, you would look into the layout, internal arrangement of the house, how many rooms do you need, etc. You would probably hire an architect to do the planning. Next you would have a construction authority work on the type of material you would like to use, how many days you would like the house to be up and complete in etc. Once all these details are laid into place, the construction will finally begin. Before you begin the construction you would probably want to check every small thing possible, like the soil beneath (sometimes it could be the one in which the house might sink), weather conditions etc.

So be it with any product. Before you start coding, you check through the specs. Check through is a wrong choice of words. To put it mildly, you tear the specs apart. Think about every possibilty.

Lets go back to the house. Your architect lays out the entire plan and you start the construction. A few months down the line, the house is built and you move in. You love your new house but your master bedroom is on the eastern side of the house, which is right next to Interstate - I 95. Passing cars and trailors all night keep you awake. The guest bedroom on the other side of the house is perfectly soundproof and your visiting mother-in-law enjoys the perfect sleep! The guest bedroom is too small for you and your wife to move into... oh only if you had thought about this I-95 before!!

So is it with software. Having the specs does not mean the product is ready to code. Read the spec and start thinking outside the box.

Lets pick a small part of a spec as an example. In this case, lets suppose you are building a product for Company XYZ. XYZ has its small team of technical staff which pens down the specifications document and sends it to your company (usually in house projects have PM's or Dev Teams take up the spec writing respobsibilities). Now, if you belong to a company which believes in good development/testing practices, your first task will be to review the specs. So lets take the following as an example:

Specification version 1.0

1.Shall read from a database file at startup if one is defined. On process termination, it shall save any entered data to the opened file.

First off, company XYZ has provided you with specs, which puts you in a better position than many other people I know (yes, sometimes specs are not provided). If you take every spec and start coding, you have missed an important step. An ideal practice at this stage would be the dev. team starts a lot of designing (on paper) and prototyping. Some prototype code is a common practice. The test team starts working on determining test cases and reviewing the specs (the dev does this too, but somehow they always manage to finish the review much much earlier than test and are knocking to tests door to ask when they can start coding). I shall get into the mentality of these two teams later. For now, being part of the test team, your focus is the specs.

Lets look at no. 1. Shall read from a database file at startup if one is defined. Great! Works for me. Sounds simple! Here is the problem. What if one is not defined? What if the one defined does not exist? Is not accessible (locked?)? What will the program do then? The spec does not state that. Rather than making your own assumptions with what the product should do, go ahead to Company XYZ and ask them what they expect it to do. Provide some options:Option 1: "Should we say - File not found, enter another file"Option 2: We could say, "File did not exist, taking demo file and displaying results to show functionality of product"

You have an ambigious spec clarified. A potential flaw has been averted! Imagine if you had taken your own decision, displayed Option 1 and during qualification (demo) XYZ says they wanted Option 2. The change in this case might take a few hours but imagine something huge for critical systems? Also imagine if this chage you make breaks something somewhere else? Wouldn't you rather spend a few extra weeks on the specs and get them clarified than have clarifications after the product has been developed?

Lets go back to the house. You finally cant bear the vehicle noise on I-95 and you break a few walls, make the guest room bigger and move in there. In this process you are set back by a few thousand dollars and possibilty of maing your house structure weak.

So will it be with any product. A bug fixed towards the end of the product development cycle not only costs more to fix, but could break the software in some other area, making the whole product weak in its structure.

So irrespective of you being a test or a dev or a PM, just forget what you are, think you are a team, and work with each other to produce a brilliant spec. You will be doing everyone around you and yourself a huge favor and missing out a few sleepless nights.