Software is a lot like a human body. Our software and our bodies grow and
evolve, demonstrating many of the same needs and functions.
Just like modern medical facilities and treatments, modern software development
infrastructures and tools exist today to help us to ensure
the wellness of our software. We know that you shouldn’t just see your
doctor for injuries and you shouldn’t just test for know defects. Kent Beck
asserts that, like our bodies, software health can best be measured best when under
duress; that the true measurement of health is how an organism responds
under stress.
During the time that software is being developed we can think of it as a living thing,
not unlike a novel in progress. Our living software has needs that must
be met in order to maintain a its’ wellness.
Contemplative Change
The healthiest changes that we make are concerted, decisive ones. For example,
I took up karate with my children 18 months ago and am in notably better shape as
a result today. It took me a while to decide that I was going to do this and
it took even more of an effort to bite the bullet and get started.
Adding new features to your software should be done as the result of a methodical
and studied decision. This is why we have Product Managers, specifications,
and the Rational Unified Process .
Making the decision to add a feature is a base admission that your software needs
improvement. Whether it means getting stronger, gaining endurance, or adding
a new dialog, the first step toward positive change is a decision that the change
is needed.
We plan and then execute the change if and only if we are dedicated to seeing it through.
Not being committed leads to a half hearted implementation.
Predictable Growth
Things change, so plan on it. My once 19–year-old six pack is more of a
40 ounce single these days. I could certainly have avoided the one-pack if I
had simply planned on the changes before they occurred and taken preemptive
action to stay healthy. Maybe I could have started the karate thing 10 years
ago.
Remember that your software is bound to change, so plan on it. Use an extensible
architecture that lets your software grow over time without turning into spaghetti
code. It would be a simple decision to use log4net as a way to write a
log file instead of writing to a FileStream. Think about the advantages
of this over time; for instance perhaps you want to go back into the application
and reformat your log files to XML. If the logic is compartmentalized into the
log object model, the change is relatively simple, not so if you are looking for all
of your .WriteLine() statements with CNTRL+F in Visual Studio.
integration, unit testing, automated regressions, and repeatable stress testing alert
us to weaknesses and defects in our software as soon as they are introduced.
This allows us to back out or fix our mistakes early, staying healthy without significant
injury.
Continuous Monitoring
Now that you are dedicated to exercising, pay attention to the results. Take
your pulse, over time it should be better. Monitor your active defects, over
time they should decline and stay there. Send build notification emails.
Look at your code coverage analysis reports and ensure that all of your muscles
are being exercised.
Attention to Illness
When your defects start to add up, fix them. It is much easier to lose 20 pounds
than 50, so don’t let it get that bad. Set a reasonable maximum defect
count and if your software exceeds that number, stop developing new code.
Fix defects first. I know it is hard, you want to keep making progress toward
your latest goal, the defects are ‘old code’ and that stuff is boring.
This is simply a matter of self discipline. You don’t have to like it every
time, you just have to do it. If you choose not to adhere to your maximum defect
count, your software will not stay healthy for long. Do not allow others (like
Product Managers) to talk you out of keeping your software healthy. Just like
your college buddies who want to take you out drinking, they should only be indulged
occasionally. I mean, have you looked at their guts lately?
Conclusion
If you treat your body and your software with these same five principals, you
and your product can grow old together.
- Contemplate change before it occurs
- Plan your growth
- Exercise
- Monitor your progress
- Pay attention to illness
Sometimes you should say “to hell with it” and go out drinking, but that’s what private
branches are for.