All Posts in Technology

|In: Industry Commentary|Last Updated:

Random thoughts:

Richard Cunningham connected some dots I’d missed with last week’s column about the need for consensus in product design. Because, he said, each element of design (engineering, marketability, manufacturability, design, profitability and so on) affects all of the other elements, “… it seems like compromising is a process of each party accepting something suboptimal to what they want for the good of the overall result.”

Bullseye. Consensus leads to superior results when all participants are committed to a common overall purpose. When that isn’t the case, even a room full of geniuses becomes a collective idiot.

Among those not committed to a common purpose are the purveyors of spam; the common purpose to which they aren’t aligned is the health and well-being of the Internet they rely on — a classic example of Garrett Hardin’s “Tragedy of the Commons.”

Spam has no clear definition. To some, it’s any unwanted e-mail — a definition that is clear but circular. To others, it’s unsolicited promotional e-mail that’s sent to a large list. I’ve already critiqued that one; it doesn’t hold up to scrutiny.

I have a new definition, or at least a new criterion, which if not comprehensive is at least immune from what scientists and diagnosticians call “Type 1 Errors,” otherwise known as false positives. It’s this: If an e-mail’s Subject line, auto-preview, and content aren’t consistent, it’s spam. If the sender has to trick you into opening a message, there’s no question as to whether it belongs in the junk bin.

What I don’t understand is why anyone bothers to send stuff like this. Whether it’s physical direct mail or promotional e-mail, if you know the recipient won’t be interested before you send it, what’s the point? I always figured it was to make money, but with these the only possible result is aggravating the recipient, with no hope of a sale.

Why cheat when it’s pointless?

It’s a question that comes up over and over again, as when reading about multibillionaires who violate insider trading laws to make a $50 thousand profit, or when looking at Microsoft’s Windows Genuine Advantage license validation program. Advantage? Sure — and down is the same as up only farther. Microsoft seems to have launched it without first making sure that (1) the software works properly; (2) its database includes all vendor pre-installs; and (3) its technical support staff have been properly trained to always give the benefit of the doubt to the caller.

Ed Foster has been reporting on this story. The short version: It appears Microsoft is requiring lots of people to pay it for licenses they already own.

I hope it’s an example of Napoleon’s dictum that you shouldn’t ascribe to malice what you can explain through incompetence. Otherwise it’s an example of cheating when you don’t have to. There just can’t be enough money involved for this to matter to Microsoft, in spite of its whining about pirated copies of Windows XP.

If you add Microsoft’s cost of tech support calls, this one-license-at-a-time approach has to cost a lot more than going after those who sell the pirated copies in bulk. Beyond that, the odds of someone filing a class-action lawsuit are, if I were to calculate the odds, approximately certain, and Microsoft will spend more to make the lawsuit go away than it can possibly be making with this program.

This would seem to be a perfect opportunity for those promoting desktop Linux. It would, except for one small problem: Whoever is responsible for desktop Linux’s success is doing their best to make it a chancy proposition for CIOs.

Oh, I forgot. Nobody is responsible, and the result is that, more than a year after Open Office 2.0’s official release (the version you need if you want to exchange files with MS Office without dying of acute annoyance), it’s still listed as “test” for at least the widely used Debian distribution — the basis for some of the more popular desktop Linux brands. CIOs don’t want to wonder whether the software they need will be compatible with the Linux version they choose. They’re looking to reduce their headaches, not make them worse.

Which brings up an important question: What is the point of making the various Linux distributions different enough that software stable on some is unreliable on others?

The open source “community” represents itself as having common goals and purpose. That must not be the case, because if it was, its members would be willing to make the minor sub-optimizations necessary to achieve easy compatibility among versions.

Clearly, they aren’t in consensus.

Comments

|In: Organizational Effectiveness|Last Updated:

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.

Comments