Policies and Procedures – Page 75 – IS Survivor Publishing

The Kludge Index

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.

SOXsessful projects

I fell in love with a client’s CEO a couple of weeks ago.

Platonically, that is. He’s an immensely successful entrepreneur, and we were discussing the value of his instincts for the business. “I don’t believe in instinct,” he told me. “I believe in evidence.”

Which brings up the recurring subject of Sarbanes-Oxley, why so many implementations spiral into out-of-control fiascoes, and what you can do to avoid that fate if you’re on the hot seat for bringing your company into SOX compliance.

At the KJR Conference last March, Jeff Sakamoto, then-CFO of Cyanotech Corporation, and Danielle Stariha, Director of Internal Audit for Gander Mountain Company shared their thoughts on the subject. Since they both managed to bring their companies into compliance on time and within budget, their thinking was well worth hearing.

I’m not going to try to summarize everything they said. They provided too much valuable content to easily summarize in a column or two, and much of what they had to say is similar to what’s been published elsewhere on the subject. Here are a few points you might not have encountered before, that will help you through your own efforts to become and stay SOX compliant:

It’s basically a good idea — having clean books and effective controls. What SOX requires of publicly held companies are practices they should already have in place. If you start your SOX program with that philosophy you’ll make much more progress much more smoothly than if you start with the attitude that it’s something you’re doing for the Feds.

It isn’t a good implementation of a good idea. Regrettably, like so many good ideas voted into place by our elected representatives, the good ideas were turned into a furball of documentation requirements. With SOX, if it isn’t documented it isn’t happening. Live with it.

It’s a project. Scratch that — it’s a program, which is to say it has multiple threads of effort (initiatives) each of which consists of multiple projects, each of which must be managed well, just like any other project. It’s banal, it’s obvious, it isn’t worth saying … except that it must be, because one reason many SOX efforts go bad is a failure of basic project management.

Master the subject. Your audit partner or some other SOX consulting experts will do a lot of the heavy lifting for you. That makes it an outsource, and like any other outsource, if you don’t know what’s going on you deserve whatever happens next. Another name for Sarbanes-Oxley is the Full Employment for Auditors Act. That doesn’t mean you have to be the one providing them with full employment.

Your CEO’s attitude tells the story. If your CEO is like our client, preferring evidence to instinct, you have a chance. The starting point for SOX compliance is a CEO who uses the accounting system as a tool to help understand What’s Really Going On Out There.

We have Sarbanes-Oxley because too many CEOs consider their company’s shares of stock to be a product, and their financial reports to be a marketing tool for that product. Marketing is about persuasion — about spotlighting the most favorable facts, de-emphasizing the least favorable facts, and describing those that are open to interpretation from their most favorable angle.

The other reason for Sarbanes-Oxley is that many CEOs make it known throughout the enterprise that Bad News Isn’t Welcome Here. Never mind shareholders and the Wall Street Analysts shareholders listen to. Their desire to hear what they want to hear instead of what they need to hear is overpowering. They trust their gut, believe in their instincts, and if the facts say otherwise then you’d better adjust the facts to match their reality.

The question is what to do if you work for a CEO like that (and here I’m going beyond what Jeff and Danielle presented: Neither described their CEOs this way).

Being responsible for SOX compliance doesn’t empower you to fire the CEO, much as you might want to. Your choices … your choices if you want to be effective, at least … are limited to one: persuasion.

Start with the first tool of the effective persuader — empathy. Say, “I don’t like it either, but we have to do it the SOX way whether we like it or not, and SOX doesn’t have a lot of wiggle room. We might as well be as efficient about it as we can.” And if you don’t feel any empathy, that’s okay — you don’t have to.

Pretend.