There comes a time in every large project when doing the Wrong Thing is the right thing to do.
There can be many reasons for this. Schedule pressure is the most common; there’s simply not enough time to figure out what the Right Thing is, and the Wrong Thing clearly (mostly) works; it’s enough to make a milestone or get upper management off a team’s back. Or there may simply be no obvious Right Thing to do; something unforeseen has come up (or the requirements have changed) and the current design just doesn’t fit. So you cut and try and hack something in, mark it “BUGBUG” or “ARGH” in the source code, and kick it out the door.
You can judge the quality of a system’s code and the mettle of the team behind it by looking at these reactive changes. A well-designed system will take a kludge in stride; the Wrong Thing will live as a minor change, to be scrubbed out in a future release. But in a poorly designed or badly managed system the Wrong Thing will metastasize and spread into many areas, essentially becoming a feature in its own right, with its own requirements, testing resources and maintenance costs.
So there are really several aspects to how systems react to kludges. First, of course, is whether the kludge has to be applied at all. How early in the product’s life is it [kludging early is a bad sign]. How extensive are the changes? How long does the kludge live? Are kludges applied often, or are they agonized over and removed as soon as possible? Are kludges necessary in the field, and do customers have to know about them to make use of the product? Are customers kludging?
A good kludge is like a wart; its effects are localized and it can be rubbed out with a little effort later on. A bad kludge is like a knife to a vital organ; its effect may be local, but it has systemic fallout. A truly terrible kludge is like a poison; once applied it is nearly impossible to remove, because it is everywhere — in the worst case the system will survive, but not without debilitating, painful impact on maintenance.
If your organization is in denial about the state of its quality, then everything may seem like a kludge. You can’t see daylight for all the pieces of conditional compilation, special cases, simple inadaquacies and hacks that have proliferated. I’ll talk about this in a later rant.
Surviving a Kludge
Be honest. Understand that it’s a kludge and be public about it. Don’t sweep it under the rug, where it will fester and breed. Be liberal in checkin comments. Don’t pretend that the wart is a beauty mark (“We’re pollin’ for arriving bytes because we use less stack” or some folderol).
Leave evidence. Even if it’s a stubbed-out function or a simple BUGBUG comment in the code, make sure there’s a placeholder for the Right Thing. If you don’t know what it is, stick something in there.
Peer review. Kludges should get special reviews. Someone else may think of a better way to solve the problem, or may have solved something similar. Heck, in a large enough system three other people have probably solved the problem; pick the best one.
Fix the problem. ’nuff said. Before your next release, if possible. Before the end of the day? Beauty.