Artful Bug Squashing

Bugs are just a fact of life in software development: nobody likes to see them, but so many demands confound a programmer’s time that it becomes impossible to design down to every last exception. Sometimes the bugs even pre-exist in the tools that we use, the development environments, or the compilers.

However much I’m reluctant to admit it, all the same we’ve got a vested interest in keeping a fair share of bugs in the works; if our offerings are perfect then we essentially program ourselves out of our jobs. Imagine if all the schoolkids picked up every last piece of trash and wiped down all the tables when they finished lunch. What would all the janitors do?

You can prevent some bugs by utilizing certain development techniques. One of my favorites is to rename all of your variables and functions to make them distinctively descriptive and non-overlapping. This adds another couple of days to the project, but in the long run it pays off twice: first in easier maintenance with standard names. Second the process of editing and replacing catches many bugs by itself.

As I mentioned in an earlier post, another useful trick during development is to make specific plans to keep audit trails (or trace logs). I usually ask the staff to define a global Boolean called Testing that when true should cause nearly all activity to log to external files.

When persisting to a database I prefer to avoid deleting records: instead I include an “obsolete” flag and set it True when the record should be ignored. Depending on the audit requirements of your system you may even prefer to append a copy of a record for modification, so that if necessary you can always go back to prior versions of a row (note however that this strategy is quite costly from a storage perspective).

Legally many systems also need to track the identity of the user and a timestamp when any rows or fields were modified. If you also include a field to identify the module name and version of the modifying process you can greatly aid version-debugging and historical corrections.

Tracking and fixing bugs is an art of its own. Under pressure rank a bug’s squash-priority by the nature of its criticality. Certainly items that involve the health and safety of your clients, your staff, and yourself come first. Items that adversely impact production cycles are the next highest importance. Bugs that interfere with someone accomplishing their work come in third (especially if you lack an immediate workaround).

Next you will have a large hodgepodge grouping of nuisance bugs, resource bottlenecks, and business-critical enhancements. Everything else will likely go into the bottom of your priority list for “when you have the time”. A useful trick-of-the-trade is to dedicate one-half to one day each week for the lowest priority items; that way you can at least address some of them. Keep the list of unfinished items however… at some point several months to a couple years down the road you will want to revisit many of them to see if they still have merit.

Artful Matchmaking

Fanning the spark of an idea for an IT project is always a tricky, precarious task. Somewhat like internal marketing, a Business Analyst is selling a vision. More than this however the analyst mentally surveys the capabilities and availabilities of everyone he knows and attempts to match this to a vision that he can impute to the desires of management. So it feels very much like matchmaking, except in the business-to-project realm.

To the managers you are selling an investment. Your job is to convince them that they will get an honorable and lucrative return on their investment in equipment and manpower. To the software developers you are selling professional advancement, knowledge enrichment, and a reasonable amount of job security.

And similar to romantic matchmaking sometimes you have to use a bit of deception in order to get the parties together despite their different opinions. Many times you will actually have a deeper awareness of the best interests of the managers and programmers than either party will know alone. Hence a bit of artful promising goes a long way. Is this unethical? Not if you're careful to make sure that the ends justify the means.

It's all about some balance and possibilities and getting folks over the hump of their current comfort levels to move them through a low spot to finally arrive at a new, higher comfort.

When an idea is just a concept -- before it is even a glimmer in a manager's eye -- when it is just a spark of "I wonder if it might make sense..." or "maybe we should look at..." the Business Analyst combs the psychic brainwaves of the company's employees and decides what is Possible.

Artful Independence

If you design things from the start with testing in mind, then your finished system will be both stronger and easier to maintain. One way to accomplish this is to provide a "testing" checkbox (or menu pulldown) in your user interface. Doing so causes a complete design cascade in how you think about development.

It sort of provides you the same comfort level as if you were slipping behind the wheel in a Driver's Training car. It feels like authentic driving but with the added safety that if you forget to step on the brake you actually won't damage anything, as the instructor is watching out for you anyway.

It also allows you the wonderful opportunity to test production interfaces with a development-version of the backing database. Using this practice also promotes looser coupling between components. Of course, make it abundantly clear on the interface (say by changing the global form background color) when the client is in test mode.

This design method does incur some additional logical overhead. Usually you will set a "Testing" Boolean and have places where you evaluate it to set, for example, the database connection strings. This means you also have to provide both the production and development paths and parameters in your config fie.

The saving grace with this approach is that it pretty much clears you from the embarrassment of the all-too-frequent mistake of accidentally copying the development parameters into the production installation. So declare your independence from installation woes: code for testing from the outset and make the development configuration selectable from the interface.