You're example involving Word and Excel made me grin because I've created more than one solution like that, taking data emailed from an online form into Word to rearrange it and delete the field names before importing it into Excel.

Around here in non-IT land, I seem like a genius for being able to come up with such a kludge, but I recognize that it's so far from ideal. Especially when someone then decides they want a new field added, blowing all my macros back to bits, pun intended.

This is a great example why I wish we had an IT guy.

I would add 3 things:

1). Kludges normally are inflexible;

2). Kludges usually travel in packs;

3). Kludges are often difficult to understand. They are almost never documented, so the circumstances of their creation, use and obsolescence are mysterious.

As Bob said, they are a patch, and a decidedly temporary patch at that. When implemented that way there is a real world place for kludges. Most live far longer than they deserve.

Kludge Electronics was a firm who "enhanced" the performance of CAA air traffic control gear in the 1940's and 50's under competitive bid. I believe they were located in Kansas.

Since they were low bidder, their work was "flimsy", as opposed to "sturdy" as was the original gear.

In the 1960's, I had the opportunity to look at vacuum tube VHF radios removed from an airport tower. These were mil-spec rack plug-ins built like a tank. On the front was a small nameplate added after the initial manufacture that said something like "modified by Kludge Electronics under CAA contract xxxx". If one turned the chassis upside down and removed the baseplate, it was easy to see where someone had cut out several components (resistors and capacitors) from a terminal strip, wrapped the wires around new components and soldered the whole glop together in mid air.

Now I'd like to remind you that this was a 120 or so mHz VHF receiver, probably with a 10.7mHz IF, and it really is quite common to see strange wire "gimmicks" used to tune the circuits of 1960's FM tube receivers.

Nevertheless, it is easy to see what generations of engineers raised on lower frequency gear with all components neatly soldered to terminal strips might think with some derision... ...until they tried to neaten up the fix and found that the radio no longer worked, so they sent it back saying it was no good. Back came the bill that stated they had made unauthorized modifications which had to be repaired! I can imagine the bad blood!!!

Kludge had created something that worked. Never mind that it didn't look pretty. It was as disruptive a technology as printed circuit boards were (but they looked neater!) and lowered manufacturing retrofit costs.

There are numerous other cases where a patch or repair ends up showing some inherently poor quality in the original design. Don't blame the one who applied the band-aid, fix the real problem. (are you listening Microsoft)

I have a programming book written in the 1970s that discusses programming style and elegance. Kludges were known about back then, yet after 30+ years, they are still with us, numerous as ever. Why?

One problem I find - quite a few people at all levels (coders, managers, technical managers, experts) are unable to recognize a kludge. I have worked with managers and co-workers who, if you built a system exactly like Bob described, would think it was perfectly fine. If you attempted to explain to them what a kludge is, and why the kludgey system is kludgey, you'd get a blank stare and a statement something like "Well, it's working just fine; leave it alone, don't break it". Or, "If it ain't broke, don't fix it".

Since a lot of what we IT folk do depends on consensus, or at least is made very much easier when everyone agrees to the proposed course of action, the presence of even a few people who are "kludge-blind" can really stall a kludge-replacement effort. So can simple economics and the need to prioritize new work higher than rework.

Another problem I find is that I don't recognize kludges I create myself until I've done whatever it is twice. The first XML programs I wrote are all kludges; I parsed the XML myself instead of using parsers. The first Java, and SQL, and Unix scripts I wrote? Kludgey. First systems I architected? Kludgey. First ETL processes? Kludgey. First non-static websites? Kludgey. Get the idea? If I were making Shoji screens, I'd serve a one-decade appreticeship under a Shoji master who would correct all my mistakes. Guess what? Masters don't exist who can show us the best way of doing something that has never been tried before. Which puts the responsibility back on us.

I'm not a particularly stupid programmer, I think. I recognize my own kludges, in hindsight. I also recognize kludges someone else created, that are in systems similar to ones I built. But I didn't recognize my own kludges at the time I was making them simply because the things we do are hard! It was all I could do just to get the product/system to work.

I have only been able to see how I could do it better, if I had to do it a second time around, after 1) mastering the craft as only one who has actually "been there, done that, and produced a real product" can, and then 2) looking back at the finished product.

Suppose other IT folks are like me. How many of them have really "been there and done that" in some particular area? Not many; skillsets don't usually overlap that much, and there are lots of different systems in most workplaces (tens of major ones in my organization; hundreds in total). So the pool of people capable of distinguishing between a kludge and something better is low.

Then add in the "final straw" and you can see why it's so hard to stop kludge proliferation. I said I could only reliably recognize kludges when I'd already "done it once before". I've been in IT for 30 years now. You know how many times I've done anything more than once? About 3. The field changes so fast, and so do the requirements, that I'm always working on something new.

I suppose that there are people who can look at a never-thought-of, never-before-created, reasonably complex computer system at its inception, and develop a complete mental picture of how it should all hang together, and recognize kludgeosity before it gets instantiated, and avoid it. Not I. If you are like me, you almost never are able to practice kludge recognition because you're always in the middle of something brand new. You can only see in places you know to look, and in "the land of new", there are unknown hiding places all over the place.

Good luck to us all and may none of your kludges be come back to haunt you.

Reading the comments on your use of kludge, I thought you may be interested in the background of the word. I've used the word kludge for years, but it wasn't until I took a printing class that I saw the origin for what this word came to represent. You've probably watched those old westerns where the local newspaper guy is working at one of those semi-automated printing presses with the huge flywheel on the side. While a sheet of paper is being squeezed between the ink covered type and a flat chunk of metal called the platen, the pressman picks up a blank sheet of paper, waits for the platen to open, takes out the printed sheet of paper, places a blank sheet on the platen making sure it is properly aligned, the platen closes again to print on that paper and the pressman gets the next blank sheet ready. If you got good at it you could run off around 2,000 copies an hour. At that speed, the platen is open for less than 2 seconds. Don't daydream or lose your focus or you'll be able to read all about it on the back of your hand. Abel & Eneval Kluge invented an add-on contraption that automated the entire process with moving rods and vacuum powered fingers. Yes, it was amusing to watch, but it worked. Sort of looks like any device you'd see in one of those wacky inventor movies. Read some more about it at http://www.brandtjenandkluge.com/company.htm.

BTW - I also ran across a great acronym from Kludge - klumsy, lame, ugly, dumb and good enough.

Marshall

The only way I've found anticipate clean, maintainable design is by distilling out a few guiding principles and techniques from 20+ years of programming. Applying those methods automatically to any new task has improved the reliability of my programs and reduced development time.

The comment about the Kluge company's paper feeder being the origin of the word is really only part of the story. In fact, this is a word with multiple possible origins, and it may well be that that it derived from more than one source.

It is widely believed that kluge may derive from the German "klug", which may be translated as "clever."

Another story is that the word derived from a Scots word "kludgie", meaning an outdoor toilet, that was later used by Scottish engineers to describe a temporary solution to a problem, or impromptu addition.

Interestingly, the Kluge company has denied that their paper feeding product was the source of the word, and they pronounce their name kloo-gay.

We'll probably never know the true origin of the word, and I suspect it's one of those cases where more than one source came together, synergistically reinforcing each other.

Wow -- fun reading!

Here's my 3.1415926 cents worth...

As a recovering physicist with a degree in music,
and as one who has made my living in high tech most of the time, I offer this bit of seasoning for the discussion:

"There's ALWAYS a tradeoff!"
-gs

No matter what one does, there are usually MANY
choices on the way to a functional system, and one must weigh one's decisions with care, or the outcome will necessarily be a bit of a kludge.
A famous related question:

"Why is there never enough time
to do it right, but always enough
time to do it over?"

Design DOES matter, (yet) good design requires
the TIME necessary to do it! Management rarely
fathoms this, in my personal experience.

Also... while I'm at this...

I remember learning early-on the engineer's line:

"If it works, use it!"

Well, yeah, but only when you're in the experimental stages of a project. A properly
engineered device is DESIGNED to work well
and to KEEP working (if properly maintained).
But again, this usually requires serious time.

OK, enough from me. I'll close with this:

"Fast, reliable, or cheap.
Choose two!"