The kludge index

In a comment posted on the kludging thread (“About kludging,” June 14, 2006 and “Fixing an interface kludge … or not,” June 15, 2006) Stephen Bounds wrote:

Since Kludging could (in theory) hire someone to write a single replacement for the two systems, this *has* to be seen as a workaround, doesn’t it? Which leads to an interesting question — what’s the difference between a kludge and an multi-step standard operating procedure like the above? Is it documentation?  Management approval? A prohibitive price to build a system to avoid the kludge? Unless we get some clear guidelines, Bob, it’s beginning to seem like “kludge” = “SOP” much like “terrorist” = “freedom fighter”. Bounds makes a good point. It’s all well and good to define a kludge as using a band-aid to attach a box to the side of the box that’s affixed to the main system with chewing gum and duct tape, but that doesn’t do much when the time comes to design a solution to a system problem. I’ll make a start here. Add your comments and I’ll do what I can to turn the result into a future Keep the Joint Running.

• Kludginess isn’t binary. There’s a continuum that runs from elegant design at one extreme to Rube Goldberg at the other. The ideal would be to define a kludge index whose value ranges from, perhaps, 1 to 5. 1 is a thing of beauty and 5 is something you wouldn’t want your mother to see.
• The more different technologies you include in a solution, the more of a kludge you’ve built. Solving a programming challenge with a combination of C++, Java, JavaScript and PERL is more of a kludge than solving the entire programming challenge in one language.
• The more steps required in the solution, the more of a kludge it is.
• The more fragile each step is in the solution (dependency on an exact data format is an example), the more of a kludge it is.
• Using tools to accomplish tasks for which they aren’t designed or intended adds to the kludge index.
• If, when you diagram the solution, lots of lines have to cross each other, there’s a pretty good chance you’ve designed a kludge.

That does raise a question: If a reputable vendor is selling a product which, were you to open the box, has a kludge metric of 4, but you never have to open the box, from the vendor’s perspective it’s clearly a kludge … but is it from your perspective? I’m thinking in particular of some enterprise applications vendors that have extended their range through acquisitions, gluing the acquired pieces to their core system through middleware of some kind without ever harmonizing the underlying design assumptions. So long as it never becomes your problem, is it still a kludge? – Bob