n. Slang
- A system, especially a computer system, that is constituted of poorly matched elements or of elements originally intended for other applications.
- A clumsy or inelegant solution to a problem.
The spelling "kludge" was apparently popularized by the "Datamation" cited below which defined it as "An ill-assorted collection of poorly matching parts, forming a distressing whole."
The Kluge Scale (As defined by Bert)
Level 1 - Special Case - You create a rule, and then violate it for a special case. Rather than alter the rule or create another rule or find a higher abstraction to accomodate the rule in your system, you write code that bypasses the rule and executes special logic when an object meets certain hard-coded criteria. And since this exception has been addressed at the lowest level possible (direct hard-coding at the point of use), it will likely have to be replicated throughout the system.
Level 2 - Jedi Mind Trick - You intentionally deceive the system. "This is not the object you were looking for." You manage to force a piece of technology to do something it wasn't meant to do by circumventing its interface, or faking out parameters, or directly manipulating its data to make it think it's doing something it's not. One reason for this kluge might be to reuse some small part of an object without reusing the whole thing. This paricular kluge is fragile. It is at high risk for future changes that cause your trick to backfire, or that allow the system to see through your deception. Since you have told the system a "lie", you now have to account for every possible logic path the system might take based on that lie. And quite likely you will end up with a system doing the wrong thing.
Level 3 - Frankenstein - A system or piece of functionality built out of parts that were not originally intended to work together. This generally requires the use of Special Cases and Jedi Mind Tricks at the points where the heterogeneous parts are joined. A Frankenstein can be one small misfit, like storing a piece of data in a column on the database that was originally intended for something else. Or a Frankenstein can span multiple systems that were never designed to work together, and thus become a "Distributed Frankenstein". These quite often turn into Rube Goldberg machines.
Level 4 - Rube Goldberg - I don't have a way of flipping this switch directly. So instead I set a piece of cheese on a mousetrap, and eventually a mouse will come to eat the cheese, and in doing so the trap bar will spring up (and hit a safety bar so we don't kill the mouse) and this will pull the string that turns on the fan that blows the little sail-boat across the tub...and so on. A Rube Goldberg happens when pieces of a system can't even be Frankensteined together, and so some other number of mediating (and ugly) pieces have to be written in order to attach the foot to the forehead.
Level 5 - Neural Net - Due to time pressures, or lack of understanding, the entire system was developed in a neural-net fashion. Neural-nets (a form of Artificial Intelligence) learn purely by a feedback loop, by trail-and-error, without any conscious awareness of the actual meaning and desired outcome.
The system evolves by having every conceivable path hard-coded into it. The system has no independent structure or "intelligence" to it, and so it fails every single time it encounters anything it hasn't seen before. And each time a new logic point (or path) is added, it risks overriding or breaking any number of previous logic points. Over time, the system will develop a sufficient number of logic points to where it can mimic having "rules". (Like a computer that can mimic understanding Chess by sheer processing power.) But they are artificial rules without structure and awareness, and you can no more debug such a system than you could debug a brain. The internal structure is chaos, and full of useless steps and dead-ends, and more dead code than live code. Take a Rube Goldberg machine and drop and entire junk-yard on it. That's a Neural Net Kluge.
Another way a Neural Net can form is when different coders work on the same system over a long stretch of time without proper documentation and attention to architecture. Rules are applied, but they are applied in different ways at different times by different people, often using kluges to make changes. The next developer that comes along only sees a Neural Net of logic where the rules aren't visible, and this poor hapless coder can only make changes in the system through trial-and-error of manipulating paths and data points and testing the results.
Level 6 - Neo kluge - Named after the character "Neo" in the movie "The Matrix". This is where you come up with a kluge that goes beyond the rules that normal software would obey. You are able to do something impossible because you work outside of the rules and the "reality" presented to you. I have written a great many Neo kluges in my career, and I shudder when I think about each one of them.
Example: My memory management routines aren't working because I made some faulty assumptions about where certain things would live at run-time. I could either re-write my program, or I could pull a Neo-kluge and alter the actual C compiler itself to put things in memory where I want them!
And the Open Source movement makes Neo kluges more common. Just last week I found myself frustrated with Tomcat's mechanism for handling JNDI realms (among other things), and since the source code for Tomcat is readily available, I made my own custom Tomcat that would behave the way I wanted it to. But as with all kluges, the negative impact will continue to grow over time until it outweighed anything positive about the whole project.
Sometimes Neo kluges are hard to avoid. Sometimes you paint yourself into a corner, and find some key feature that your whole design depended on just isn't technically possible. And in order to meet a deadline, you have to "take it to the next level" and by sheer hackery make something work by altering your very environment. But what you have created is a glitch in the matrix that will be a maintenance nightmare at best. And it has to be fixed at a higher priority than any other kind of kluge you have going.
Kluge Death
It is my belief that the highest level of kluge that can be maintained (at great cost) is a Frankenstein. But beware that too many Level 1 and Level 2 kluges will eventually turn your system into a Neural Net, so you should be vigilant in removing kluges as you find them.
Kluges happen naturally under tight time constrains, or due to current lack of understanding of the system. And that's fine for a short-term solution to meet a short-term need. But kluges represent "Technical Debt". You take out a loan of technical debt from the system to get it out the door quickly, but technical debt must be repaid someday, one way or another, with interest.
Kluges will cost you more money in the long-run than doing it right the first time.
1 comments:
Magnificent description of kluge!
I was trying to explain to a non-engineer exactly what kluge meant but could not come up with a good definition. So I googled it and came up with your blog which I forwarded. Good job!
Post a Comment