It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

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.

In World War II the French lost to the German Army, not because they were “cheese-eating surrender monkeys” but because their generals were prepared for the last war, not the next one. The French soldiers were no less valiant than their German counterparts. Their generals, however, had perfectly positioned them for trench warfare, while the German generals had figured out how to take maximum advantage of the tank.

Taken as a whole, American business seems to be fighting its own version of the last war — “Japan Inc.’s” 1970s invasion, fought with goods that cost less and held up better than anything American manufacturers could produce. Whether it was Toyota or Datsun for cars, or Sony, Panasonic or Mitsubishi for consumer electronics, they cleaned our clocks.

The sad fact is, in this war we were the surrender monkeys (who, even more embarrassingly, considered Velveeta to be a real form of cheese). We shifted our economy from manufacturing to finance and services, sending some manufacturing sectors to offshore partners in their entirety while abandoning others altogether.

At the same time, on the theory that if you can’t beat ’em, join ’em, we obsessed about process through disciplines like Lean, Six Sigma, and Theory of Constraints — not only to organize the manufacturing that remained onshore, but to organize all of the other work as well.

Which is unfortunate, because a lot of the work performed in modern businesses doesn’t fit the process model and shouldn’t be organized as if it did.

A quick refresher: Every business function has six characteristics. Depending on the function their relative importance ranks differently. They are:

  • Fixed cost – the cost of turning the lights on before any work gets done.
  • Incremental cost – the cost of processing one more item.
  • Cycle time – how much time elapses processing one item from start to finish.
  • Throughput – how much work the function churns out in a unit of time … its capacity, in other words.
  • Quality – the absence of defects.
  • Excellence – flexibility, the ability to tailor to individual needs, and the presence of cool stuff.

“Process” is, by definition, a series of well-defined steps which, if followed correctly, yield repeatable, predictable results. It’s just the ticket for mass production.

Which is, for many businesses, either the last war or someone else’s war altogether. The same may be said of many business functions, only more so.

The process disciplines all assume that “better” always means lower incremental costs, higher throughput, and better quality. When you’re engaged in mass production, that’s usually a valid assumption to make for your factory, supply chain, and distribution (although assuming such things when you can consciously decide them instead is rarely a good idea).

Beyond that? Based on my exposure and experience, very little of the work that goes on in today’s companies fits the mass production model … incremental cost, capacity, and quality frequently matter less than keeping fixed costs low, being fast and responsive, and allowing exceptions, tailoring results, and including sales-worthy features and functionality.

These characteristics lie in the realm of business practices, not business processes … the realm where flexibility, quickness, and excellence hold sway. There’s no reason to expect methodologies designed to support mass production to deliver the right results, and lots of reasons to suspect they’ll fail at it.

My knowledge, though, comes from a non-random sample. Worse, I’m as prone to seeing what I want to see as anyone else.

We need data. You’re going to provide some (I hope … please?).

I’ve set up a simple survey form. It provides room for you to enter:

  • Company name: To be used to help prevent spurious entries; deleted after that.
  • Your email address: Same purpose, likewise confidential and deleted after tabulation.
  • Business size: Estimated number of employees, including outsourced labor.
  • Four most important business functions: These are divided into two pairs. The first consists of the two that most differentiate your company from its competitors and drive business success (such as sales, product development, and manufacturing). The second consists of the two most important supporting processes (which might include recruiting, app dev, or accounting).
  • Top three business function optimization parameters: For each business function, which three of the six … fixed cost, incremental cost, cycle time, throughput, quality, or excellence … are most important.

Fill out the survey form yourself (you’ll find it here) and spread the word, too. The more organizations that are represented, the more useful and valid the conclusions will be.

In the end, there’s just no substitute for actual evidence.

One of the most powerful formulations in the persuasion arsenal is, “I used to think x. Then I learned about y and it completely changed my mind.”

In that vein …

I used to think business leaders had five primary motivators at their disposal. Then I saw Dan Pink’s video on the subject (see “Why small is beautiful,” KJR 10/4/2010).

While it didn’t completely change my mind, it did cause me to seriously re-think the subject.