The etymology of “kludge” is disputed. Some claim it’s from the German word “kluge” and should be spelled that way; others cite a manufacturer named Kludge that sold an automated sheet feeder for printing presses that worked, usually, in spite of a design that had way too many moving parts. Kludge rhymes with “huge,” even though it’s spelled like “fudge.” Wikipedia cites this as an example of English pronunciation being a kludge.

A kludge is an inelegant and fragile solution to an engineering problem — a bag stuck with chewing gum to the side of the box that’s been attached to the main system with band-aids. The question is, how do you tell if you have one?

This subject came up in Advice Line last week, where I proposed that kludginess isn’t binary. It’s a continuum that runs from elegant design at one extreme to Rube Goldberg at the other. Ideally, we’d define a Kludge Index whose value ranges from, perhaps, 1 to 5, where 1 is a thing of beauty and 5 is something you wouldn’t want your mother to see.

I proposed some criteria for the index, solicited others from readers, and thought about it a bit more. Here’s the combined result:

• 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.

• The use of multiple technologies is a warning sign, but doesn’t automatically make a kludge. Here are the rules:
  • Multiple languages are fine, so long as each is the right tool for its particular job, everything is encapsulated, and boundaries are well-defined. You might, for example, use Java for all server-side business logic, but JavaScript for user-interface programming and small routines where responsiveness is of paramount concern. Neither choice invalidates the use of an industrial-strength ETL tool (extract, transform and load) for batch to connect this application to your data warehouse. (From Warren Young.)
  • Multiple technologies make more sense than insisting on just one: The use of multiple technologies is a kludge when each programmer (or user) chooses what he or she likes and knows, not the best tool for the job. (From Kevin Morgan.)
  • Use just one tool for each technical challenge. It’s a kludge when you use more than one, solely because different staff members have different preferences. Chewing gum, band-aids or duct tape might be fine; chewing gum, band-aids and duct tape makes a kludge.

• 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.

• If the kludge is packaged by a reputable vendor and hidden inside the product where you can’t see it, it’s less of a kludge than if your own programmers had to maintain it … but it’s still a kludge and will cause your problems in all sorts of unexpected ways.

• If your own programmers hide a kludge inside a box (that is, inside a callable routine where nobody has to deal with anything beyond its interface), it’s less of a kludge than otherwise … but it too is still a kludge and will undoubtedly cause you problems in all sorts of unexpected ways. They’ll be harder to troubleshoot, too.

• “Paul” (no last name provided) made this excellent point: It’s a kludge when you take away the external symptoms of a problem by addressing only a very narrow situation instead of fixing the real issue in a general way — leaving bad design or logic in place, adding more logic to trap wrong results and fix them. For example: If a ten-foot section of pavement on a bridge fell away leaving a hole because it was built using substandard concrete, building a wooden bridge over the gap would be a kludge.

Still, no matter how bad a kludge is, it’s better than not solving the problem at all. I tried to blend this point into the Kludge Index. To do so, I needed a way to discover and rate all of the various problems that haven’t been solved at all.

I tried a lot of different ways to go about this. But every solution I came up with was just too much of a kludge.