ManagementSpeak: That’s an implementation issue.
Translation: Just give me the money and I’ll figure out what to do with it later.
KJR Club member Nick Osborn figured out what to do with this example of management hand-waving right away.
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 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.