I hate to disagree with you Bob, but simply using different technologies/languages in a project is NOT a kludge. In fact, it is often the opposite. You should use the "best" tool available for a particular aspect of a solution. Most libraries are written in languages different from consumer of that library. So, your Perl, Java, and VB apps use libraries written in C, C++ and Assembly. Very elegant solutions sometimes involve nothing more than an awk script, a batch file and a cronjob entry. Other times, a completely self-contained C++ NT Service is the solution. Other times, its a Database called from a Java J2EE service called from an Apache webserver invoked via https from a C++ DLL that is called from a VB application. I know that "seems" kludgie - but it beats the pants off trying to write a C++ MFC GUI making direct Database API calls across a network (if you want it secure it needs a VPN etc etc). Fully integrated solutions are often more fragile and harder to maintain.

Elegant programming is very often simply chaining up services together.

A Kludge is using the person.birth_date field as the death_date and putting "DIED" in the person.title field.

Here's my offering of a sample kludge. It comes via a friend, and is many years old.

A client was asking for advanced formatting features in a spreadsheet. These were the glory years of Lotus 1-2-3 and WordPerfect, and those may have been the actual products involved (I no longer remember).

The underlying reason for all the requests was that the client was writing a document in the spreadsheet. Despite the availability of a word processor, already installed, the client was single-mindedly using the spreadsheet. No other answer was satisfactory and, of course, the client was unsatisfied.

On the other hand, my friend the support analyst, wasn't having any of it. The answer was a word processor he insisted.

I submit that the client implemented a kludge solution. Use an inappropriate tool when an appropriate tool is at hand.

"Use an inappropriate tool when an appropriate tool is at hand."

That's an interesting definition of a kludge, and I think it has something to commend it.

The use of an "inappropriate" (suboptimal) tool can be the elegant solution, when the appropriate (optimal) tool isn't available or doesn't yet exist.

It also explains how once-elegant solutions can degrade into kludges, sticking to "what we've always done" when a more appropriate tool is available.

Interesting and worth exploring, I think.

Robin, I think the multi-tool kludge v. elegance debate really comes down to how they are used. Is it a kludge when I use all the tools in my shop to build a cabinet, or is it elegant? That depends...am I using the butt end of the screwdrivers to pound in nails?

We have a job that produces a printed report in less than useful form, and leaves a copy of the report on disk until the next time to job is run. I've written a program that grabs that disk file, skips the page headers and footers to read the report data, resorts it all into a much more useful sequence, pours the reformatted infomation back into the pages, and then sends it all to the printer. It's a kludge.

If I could change the original report, that would be elegant. If I could intercept the print stream and reformat it on the fly, that might be elegant. Both my kludge solution and my potential elegant solutions can involve using multiple tools. The important difference is how they're being used.

I taught Visual Basic to high school students for a couple of years in the 90's. An early programming assignment in the class involved using an algorithm to calculate and print out the numbers 0-9. When one brilliant but quirky student got the assignment, he misread it and wrote a program that printed the numbers 1-10.

As I walked around the room, I saw his error and asked him to correct it. He added a statement near the end of his program, something to the effect of "X=X-1". It corrected the output of his program, but it was a very kludgey thing to do. I tried to convince him that it was a poor answer to the problem, but he was skeptical - after all, hadn't he gotten the right answer?

I recognized a good teaching opportunity. The next several assignments for the class suddenly involved modifying that original program one way or another to skip digits, reverse the order, find a multiple of each number, etc. These operations were very easy for the students who had programmed the algorithm in a clean way, but his effort and frustration increased until he finally went back and corrected the original program.

His program was a kludge because he took away the external symptoms of a problem without fixing the real issue. As is typical of a kludge, it addressed only one situation or symptom. When it was stressed in different directions, it had to be refixed and refixed again - far more effort than it would have been to take care of the real problem in the beginning.

I agree with Robin.

One system I'm working on now has the server pieces written in C++. They communicate through a custom extensible wire protocol with ASP code running on a web server. The web server sends pages to the client over HTTP written in a combination of HTML and JavaScript. The JavaScript occasionally calls back into the ASP code using Ajax, which in turn calls back to the C++ server code. Three different langauges (four if you want to count HTML) and two different wire protocols, but everything is nicely encapsulated. It would be foolish to try to write the servers in JavaScript, or the web page generation code in C++, just to avoid the use of multiple languages.

What makes a multi-language system a kludge or not is whether its interfaces are well-defined. This gets to your point, Bob, about lines on the diagram crossing. Since you've got this point covered already, I think you can drop the multi-language heuristic.

Speaking of heuristics, you need to couch a problem like this in those terms. No single rule is going to be wholly right or wrong. The rules have to be taken as a whole, and they simply guide you to the answer, they don't give it to you outright.

A vendor's kludge IS the buyer's problem. Despite the shiny wrapper the product will have all the problems of a DIY kludge, aggravated by the buyer's inability to fix anything and the vendor's inability to enhance in anything less than geologic eras. I've learned the hard way to look under the cover.

Brian's got a point, which might be added to the kludge index: Using a tool simply because that's what one developer understands, when another tool is available that's clearly more suitable, should add to the kludge index. (I had a graphic designer friend who used FreeHand as his primary design program; when he needed to type a letter or other document, he'd create a text box in a Freehand document and use that for his word processor. Scary.)

As you say, it's not binary; as Robin said, sometimes a multi-tool solution is very workable. On the other hand, the example s/he cited (the database called from a Java J2EE service...) seems headed for severe kludge status; if not now, when the next "change" that comes along requires yet another level of interaction. Sooner or later, one part of that system is going to become obsolete, unavailable, compromised, or incompatible, and then the whole thing will break.

Alternatively, one might note that while the current versions (2.0, 3.5, 11.ac, 7.2 and 4.45b, respectively) of Tools A, B, C, D, and E are currently compatible and can sustain the chain of interaction you mention, let's posit that Tool C goes to version 12.0. 11.x is immediately deprecated and support will disappear in 6 months. Only problem is, Tool C v12 doesn't work with the chain. And can't be made to to work. And you now have 6 months to find another supported way to get from Tool A to Tool E. If there is another way.

That's a classic example of what Bob was pointing out as "the more steps required in the solution...". I've seen systems like this break and bring a business to a crashing halt--one of which never could recover.

Hmmm, Brian, so how do we resolve "The customer is always right" with "The customer wants a kludge", and the undesirability of all kludges? Ought we to conclude that sometimes a kludge is the right answer? It kind of comes down to the white rabbit telling Alice that which path she should take depended entirely on where she wanted to go...what about the potential for damage caused by the client's use of a spreadsheet as a word processor? What were the client's requirements? Was there a need to see collated replies juxtaposed? Could it be that a kludge to one is an elegant solution to another - which gets us back to the definition of the word - McGraw-Hill's Dictionary of Scitntific and Technical Terms: "A poorly designed data-processing system composed of ill-fitting mismatched components" seems to lend itself well to the "I know it when I see it" approach...I liked Bob's attempt to quantify the term, but feel more is needed.

Sorry, Bob, but I have to disagree about the "multiple languages" point, also. The phrase "right tool for the job" comes to mind.

Our particular application is in a blurry area, but it definitely has a big kludge. We have an application developed in Java - and it is definitely the right language for the job. Within the application we embed the native browser...which is unfortunately IE on Windows. In order to accomplish our task, we need to intercept traffic between the browser and the server. We are able to do this from Java by manipulating the browsers proxy settings prior to instantiating it and then resetting them after instantiation is complete. Its all in Java, but it's a kludge. I qualify it as a kludge because it breaks easily and is somewhat unpredicable. A better solution would be to write our own native wrapper around the embedded browser and intercept the HTTP messages using some Windows APIs. This would be done in C/C++, but would be much less of a kludge and much more reliable (or so we think). The kludge exists because we don't have the right skillset for delving into the COM/Win32 APIs required to do it the "right" way.

Bob has again, and it's the reason I like his work, hit the nail quite accurately.
Brian, 5th bullet.
Robin, 2nd bullet. It's a cumulative function.
A reasonable justification for a sloppy work is urgency. If you don't trash it or fix it afterwards, then it's a kludge.

(snip)-----
"Use an inappropriate tool when an appropriate tool is at hand."
That's an interesting definition of a kludge, and I think it has something to commend it.
The use of an "inappropriate" (suboptimal) tool can be the elegant solution, when the appropriate (optimal) tool isn't available or doesn't yet exist.
-----(end snip)

You can put this comment from Chris+Brian together with Robin's example ("A Kludge is using the person.birth_date field as the death_date and putting "DIED" in the person.title field."), and see why Nick is right ("A vendor's kludge IS the buyer's problem.")

It all comes down to "what does 'at hand' mean, in context"?

Here's what I mean: Robin's illustration is a data-kludge. Whether there is a "better tool at hand" is going to depend on your facility for changing the data structures. If a vendor has written an app that doesn't allow extensible data structures, and if they didn't plan for a death-date field explicitly, you're going to find users doing exactly what Robin describes, in desperation.

You're also going to find in-house IT people facilitating this behavior, also in desperation. They're going to write extraction routines around the death-data because it is the data they have, in response to a request from a business analyst.

The users see the *app*, not the implementation technology, as the tool.

And the IT people see the *data* as the tool. They can point out its inadequacy or the likelihood that it is dirty given how it got shoehorned into the system, but it's all they've got. The vendor didn't expose data extensions as a tool "at hand".

NONE of this has anything to do with whether the vendor used one or multiple technologies, BTW. It's purely a design-interfaces issue -- as Warren points out.

Hmm. A discussion in which pretty much every participant is contributing something worthwhile. That's gotta be Bob Lewis at work :-) .

A simple description of one type of kludge is: Any add-on that provides a function or outcoume that the system was not designed to produce. As in Paul's student adding x=x-1 after the script was written. The best was I know to reduce kludges is to determine ALL desired outcomes before designing the system. Of course, sooner or later, someone is going to want something more from your system and that is when the kludgery will begin.

Or take the well designed and built cabinet with lots of shelves. Eventually, someone will want to separate items by size or type and you are adding shoe boxes or some RubberMaid space saver thingie.

Each of those boxes and the space saver is a kludge.

Bob,

Actually, having a built-in 24 hour delay on comments appearing is daunting, and, well, kludgey...because it interrupts the flow of the dialog, the fundamental requirment. Please fix it.

Band aids and bubble gum. Buying up bits and pieces to add together and create something that you can use/sell to the unwashed.
Can anyone say Microsoft or Cisco? At what point does combining technologies, languages and diverse ideas move from being a kludge to being bleeding edge thinking?
A kludge is in the eye of the beholder, and everyone has a different POV and agenda.
Love your columns Bob. I certainly can't come up with all of the solutions, but the ugly questions just keep flowing.

In response to George's complaint about the "built-in 24-hour delay," there is no such built-in delay.

For every legitimate comment, I receive roughly three spam comments advertising ... well, you can pretty much guess what they're advertising. The result is that I have to personally approve all posts before they appear. I try to get to it a couple of times a day. Some days I have more time to devote to it than others.

- Bob

The worst kind of kludge:

You have no idea why the program crashed.

You have no idea why adding a certain line of code solves the problem.

IF you can't document how it work, and/or if it takes a special person to maintain it, it is a kludge.

Todd, I loved that.

But I still have a couple of questions if anyone wants to respond:

1. Since a kludge gives me the desired result, are all kludges wrong?

2. At what point do kludges turn evil and we say enough is enough, we need to rebuild NOW?

There are a couple of interesting thoughts earlier.

Absolutely the implementation of the fix that corrects the problem, without understanding the true cause, is a kludge. And it isn't that far off from the student who added x=x-1 to their program. They knew the expected outcome but didn't understand the entire problem or scope.

To properly implement a kludge or prevent a kludge you must have vision. Vision provides the insight into the problem, the full set of risks, the full requirements set and expected outcomes. Once you have them you can:

1. New development - put in enough flex to allow for the potential changes.
2. Problem fixing/new requirement - you must understand the entire system so you don't hurt performance or flat out break something.

As for the cabinets with Rubbermaid containers; if I design the cabinet with the containers in mind then it probably isn't a kludge. It could be that I want the flexibility and portability that these containers give me.

Also, Agile and XP methodologies allow for refactoring to come into play. This means that sometimes there will be a kludge to get something done, but other times the process creates an opportunity to correct earlier weaknesses and kludges, thus improving the system. (I have always wanted to us "thus" in a posting here.)

So, I haven't provided a full definition but hopefully the thread will continue to drive the solution forward. It starts looking like a systems maturity model when you think about it.

If you are ashamed to show any of your peers the source code, then it is probably a kludge.

Kludges start with a "Kludged" prject team/member. They provide "Kludged" solutions, technically perfect, operationally fragile. A Kludge factor=1 means the Kludge can service more than 4 variants of a single requirement, a factor of 5 is a solution on a single variant/dimention.

Software always bears the mark of the person behind it!

This has been a very good set of responses...

As pointed out by a few people, kludges can involve many things, but primarily they involve the implementation of code or a process that addresses symptoms or outcomes rather than the underlying assumptions.

And they tend to be very version dependent... :)