Backscatter

Need a Kluge?

By Donald Christiansen

I have been unable to locate any formal courses in how to design a kluge. Among the many definitions of a kluge is “a quick and dirty solution that is clumsy, inelegant, inefficient, difficult to extend and hard to maintain.” Another: “an ill-assorted collection of poorly matching parts, forming a distressing whole.” Note: I have used the spelling “kluge” (pronounced klooge) in this article, although its alternative, “kludge,” appears in some reference material.

Author Samuel Arbesman, in his book “Overcomplicated: Technology at the Limits of Comprehension,” is a bit kinder, defining kluge as a cobbled together, inelegant, and sometimes needlessly complicated solution to a problem.

Among the reasons that kluges exist and are proliferating is the embedment of obsolete technology in existing systems. Abandoning such systems and starting from scratch is beyond consideration. In some cases, Arbesman notes, two independently designed systems are suddenly required to operate together. To do so, they must be kluged. An example might be NASA’s Skylab. Its two major components (the Saturn Workshop and the Apollo Telescope Mount) had themselves been kluged. They were later to become part of the Apollo Application Program, where the plans were to launch each separately, then dock them in orbit. But when the decision was later made to launch them together, even more kluging was required.

With the increasing embedment of technology in all aspects of society, the term “kluging” may be phasing out in favor of “system integration.” In engineering applications this could refer to merging the component subsystems into one system so the resultant can deliver an overarching functionality.

System integration engineers are in increasing demand as more systems are designed to connect within a system under construction, as well as to already deployed systems. Organizations contemplating system integration may be reluctant to share data with other companies, as well as to outsource its operations to third parties. To overcome such concerns the experts advise clear communications and simplified information exchange.

The negative aspects of kluging has prompted their humorous exploitation. A parody, “How to Design a Kludge,” was published in DATAMATION in 1962. In it a fictitious executive of Fink and Wiggles Publishing Company explains that “the essence of proper kludge building is the designer who is so clever that he outwits himself. The method lies as much in misshapen softwaresville as in techniques of solder and scope. The proper approach lies in producing a machine with maximum unforgivability.”

Famed cartoonist Rube Goldberg was profiting from his spoofing of technology even before the concept of kluges arrived. He earned his engineering degree from the University of California, Berkeley, in 1904. He worked only briefly as an engineer before becoming a newspaper cartoonist. The strip for which he is best known is The Inventions of Professor Lucifer Gorgonzola Butts, which he drew from 1914 to 1964. In 1966, “Rube Goldberg” was defined in the Random House Dictionary of the English Language as “deviously complex and Impractical,” and the term “Goldbergian” was used to describe complex machinery. In 1995, the U.S. postal service issued the stamp shown above, depicting Goldberg’s cartoon, the “Self-Operating Napkin.”

I could go on, but I think it is safe to wager that, with the increasing complexity of systems, even more kluges, by whatever name, will be required, and their accompanying humorous put-downs will continue.

Resources

  • Arbesman, S., Overcomplication: Technology at the Limits of Comprehension, Current, an imprint of Random House, 2016
  • Perrow, C., Normal Accidents: Living with High-Risk Technologies, Princeton University Press, 1999
  • Granholm, J.W., “How to Design a Kludge,” DATAMATION, Feb. 1962
  • Hvolby, H.; Trienekens, J.H. , “Challenges in business systems integration” Computers in Industry, Dec. 2010
  • Rube Goldberg, Interview with Edward Murrow, 1959
  • Smithsonian’s Archives of American Art: Oral History Interview with Rube Goldberg
  • Marks, B., “Joking Aside, Rube Goldberg Got Tech Right” https://www.collectorsweekly.com/articles/rube-goldberg-got-tech-right/. retrieved Aug 1, 2000

Donald Christiansen is the former editor and publisher of IEEE Spectrum and an independent publishing consultant. He is a Fellow of the IEEE. He can be reached at donchristiansen@ieee.org.

Advertisement

Donald Christiansen

Donald Christiansen is the former editor and publisher of IEEE Spectrum and an independent publishing consultant. He is a Fellow of the IEEE. His Backscatter columns can be found here.

Related Articles

One Comment

  1. Systems Integration need not use kluges, in fact that is the expensive way to go. Systems can be hooked together using good design practices. For instance all kluges connect two or more systems, none of which has the interfaces required to connect them. The system integrator must define these interfaces, which must be verified. If this part of the process is cheap, e.g. quick and dirty, then the result will be a kluge, buggy, and expensive to maintain from then on. The cost of a good integration process substantially reduce the future cost and in my experience with four major system integration designs, the development costs and time were lower when compared to other “quick and dirty” integration projects. A clean design always wins the reliability, cost, schedule, and usability races.

    As to the assertion “Abandoning such systems and starting from scratch is beyond consideration.” is why Microsoft Office, Acrobat, and Photoshop Elements, among (many) others, continue to become buggier and buggier. At some point the software companies have to realize an occasional rewrite of code must be done. The driving force is the simple fact that modifying code generates substantially more bugs than writing new code. Modifying modified code is even less reliable. (This rule is recursive.)

Leave a Reply

Your email address will not be published. Required fields are marked *

Check Also
Close
Back to top button