Chip Camden admits to burying some so-called mummies in IT projects. He offers IT consultants tips on locating and removing mummies.
TechRepublic member Bob Eisenhardt (reisen55) sent me an email about an upgrade project in which he discovered a new category of IT problem: "mummies".
These are long dead and forgotten system settings that, once done years ago, are just lying there buried and quiet. On more than a few stations I had hard-coded DNS servers to be those provided by the ISP itself, so when they moved to the new domain with DNS on the server... NOPE, they continued to find DNS outside of the building with a ton of error issues.
Mummies, hard to find and easy to fix once you know where the bodies are buried.
I have to admit to having buried a few mummies of exactly the same persuasion myself. The DNS server is down, so you point to a public server just to be able to communicate with the outside world — then you forget about it until it rises from the dead looking for your brains. No, wait — that's zombies. It goes searching for its lost love... or something.
System settings such as DNS aren't the only places where mummies can lie hidden for centuries, however; they're probably even more abundant in code. Mummies are often harmless — for instance, printf debug messages that get piped to the bitbucket in a production system. Nobody knows they're even there until someone happens to run the process with unredirected output and receives a friendly "We made it!" on the console. This is yet another reason to avoid curse words in debug messages — or better yet, use a debugging facility that gets automatically excluded from production code.
More insipid and destructive mummies lurk in sections of code that have no output, nor any other useful function. You reorganized the code and either missed a section or didn't understand it, so you let it be. Now it's happily collecting an array of a million items and throwing it away on every transaction, just eating the processor's brains (wait, that's zombies again!). These mummies can lie buried for ages, unless someone happens to stumble across them. Even then, the stumbler may not feel qualified to determine whether they can be safely removed. Thus, they tend to multiply, as each successive maintainer adds a new solution that he or she can understand, to solve almost the same problem. These mummies make a good argument for regular code reviews and cleanup.
Another serious class of mummy includes just about anything "hard-coded": URLs (or God forbid, IP addresses), directory paths, array sizes, etc. Here's a good rule of thumb: If you're about to use a literal value, don't. Other good reasons, such as the DRY principle, exist for confining literals to unique central locations, but to avoid the mummies don't use them at all. Make mummies user-configurable or derive them from some other parameter instead. Try to keep all the configurable knobs in one place, too, so you and your client can easily review all of the system's settings when major changes occur. Make their location obvious instead of cryptic, so the mummies have no place to hide.
On a more general level, a good MAP (Mummy Avoidance Policy) includes the recognition of a denouement phase for any deliverable. Too often, we consultants move directly from "Ah ha, it works!" to "Ship it!" without allowing ourselves time to unravel all of our debugging knots and insure that the "ship" is indeed C-worthy (decide for yourself whether C is for "Client", "Chief" X Officer, the "C" programming language, or "Chip's Corny Cleverness").
Okay, time to steer back up the metaphoric Nile and rejoin our mummies.
I remember well the first time I viewed a real Egyptian mummy at the Smithsonian National Museum of Natural History. While I found that specimen's state of preservation after more than three millennia truly amazing, he certainly wasn't in any kind of shape to do anything productive.
Before you declare any project finished, take the time to remove the mummies — at best, they're only dead weight.