You Are What You Eat
Even without going to the dietary extremes taken on in the documentary Super Size Me, we can certainly tell when we’ve had too much to eat, when we are hungry, or when we have eaten something that doesn’t agree with us. Despite my acknowledged cravings for sweets, I know that I’m not going to be happy after the fact if I indulge in something that’s not good for me. It’s not too different in software development, where the adage of ‘garbage in, garbage out’ is an unfortunate fact of life that few of us heed.
It would be too easy to beat the dietary metaphor to death, but the bottom line is that as a system that produces software, a software team needs to be efficient and effective. We need to recognize the quality of our downstream artifacts are going to be directly proportional to the quality of their predecessors. It is interesting to note that while most software teams obsess over their source code and a growing number of teams show interest and concern over quality design artifacts, still relatively few groups respect the value of the specification of their products (and the ongoing management of that specification). We are creating an environment where we will be lethargic and sloppy in producing the very thing we care about the most – our source code.
Here’s a quick litmus test for you.
Considering the overall lifecycle of products that are produced for your projects – the specification, the design, the source, the test artifacts – your order may vary given your chosen lifecycle, of course. To what degree do you manage these products from the following perspectives?
- There is planned time in the schedule to develop the products
- There is some form of peer review of the products, and validation that these products are adequate before advancing
- These artifacts are retained under a configuration management system
- These artifacts are baselined and controlled for change, ensuring that there is a system in place so everyone knows they have access to the latest version
- There is traceability (for completeness and consistency) between these products and the other products up and down the chain.
If you do all of these well for all the components of a project, it is a pretty safe bet that you are in good project health. If you aren’t doing some of these, or not doing them as thoroughly or consistently as you know you should, there is a good chance that these deficiencies involve the earlier stage products, such as your specs. If you weren’t even aware that you should be developing and managing all these products, then it is likely that software development isn’t nearly as fun as it could be. Some projects forge ahead with nothing more than a quick list of features and rarely meet expectations, some companies don’t explicitly design their products and suffer as the product evolves – both self-inflicted maladies.
Skimping on the early stage artifacts for a project essentially means that you are missing major portions of your diet. While you may feel you can make do without them, you will almost certainly suffer from a lack of efficiency, and there is a good chance that your results will be disappointing. Jumping straight to the dessert can seem appealing, but it is certainly not a sustainable approach – the guilty pleasure of something that tastes great but we know isn’t the best for us in the long run can be quite compelling and addictive.
How’s your software diet? Do you plan your meals or try to scarf down some techno-fast-food and skip your fruits and vegetables, only to suffer from ongoing bouts of indigestion? Would your development practices resemble a planned, balanced diet of healthy foods, or a mad scramble of Big Macs, pop, and a resulting expanding waistline? – JB