That’s just a kludge! I learned this element of design aesthetic when I was in college from my friend Chris, Dr. Boyd, and others. We applied the term kludge or hack to a system component or design decision that would fix a specific, local problem at the cost of a more general, “elegant” solution. A hack makes the system work, but it ain’t pretty.

The Wikipedia article on Kludge, as of the date of this writing, seems pretty good.

Nevertheless, users of the system are often pleased as punch when the hack is implemented, because it makes the system do what they actually wanted it to do.

But why do we hate kludges so much? A kludge doesn’t solve the general problem; or, as the wikipedia author put it, “the corner cases…not expected to come up in typical usage”. As such, there’s a supposed “general problem” that we want to solve, but this kludge only solves a part of it — and possibly an important part of it. In this case, is a kludge really that bad? Or are we just less satisfied because the kludge doesn’t solve “the whole problem”, and the problem-solving designer in us wants to provide the complete solution, not just a partial solution.

Perhaps I’ve spent too much time around telecommunications, where the best solution achievable via Electrical Engineering appears kludgy to an ivory-tower-ensconced Computer Scientist like myself. I get the feeling from some telecom systems that there’s too much satisfaction with kludges. For example, there’s the software-based telephone switch that can only only do SS7 signaling on the T1 plugged into port 1 on a particular card. What’s wrong with the other ports? Shouldn’t any port that can carry synchronous data at 56kbps or better be able to terminate an SS7 link? And there’s Java-on-Linux VoIP call-control server that does database synchronization, but periodically the databases get out of sync, and you have to dump the replica and rebuild it from the primary — and that’s considered normal. Why aren’t these databases perfectly in sync all the time?

Or maybe I’ve gotten too comfortable with the we-weren’t-hired-to-solve-that-part-of-the-problem approach required by consulting/contracting, as in my current situation. We’re only usually asked to solve a problem, even using software, in a limited case — specific to what the customer wants today. We’re not asked to solve all such possible problems that are easily envisioned.

I’ve chosen not to crusade against these cases, or let them torture me. I think I’m getting OK with kludges of this sort; solving the actual problem would take far too long, and be far too expensive.

Am I wrong, though? The practice of design is about matching a solution to its environment — it’s about making something that fits. If a kludgy, partial design fits, then is that bad?