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.

As I get older, science fiction seems to have less science, which is too bad. Science is the hard work of figuring out how the universe works. It’s been replaced with swords and sorcery, which is simply wishful thinking, and as David Brin has pointed out, part of “wishful” is the assumption that in a feudal society you’d end up as something other than one of the peons who made up 90% of the population.

And so, while I wait for the next Discworld novel to appear each year, I’ve been reading more history. Regrettably, not quite enough, as several subscribers pointed out in response to last week’s column: Well before the Revolutionary War, England largely rejected the idea of the divine right of kings, replacing it with the inherent right of the aristocracy. Not that this was much better, nor do I know whether the English of the time claimed God wanted those with titles to be entitled.

People being what they are, I’d bet that they did.

Much of the rest of my correspondence had to do with the role of consensus in corporate decision-making. One source told me that a number of large corporations teach decision-making in their leadership training programs. Their programs (which, unlike the leadership seminars we provide, apparently require lexicographical activism) define both consensus and collaboration as conflict resolution processes, and then explain that consensus is bad while collaboration is good.

And if I define black as a shade of lavender, and white as a shade of tan, I can easily make the case that white suits make a better fashion statement for male business executives than black ones. “Collaborate” is widely understood (and defined in dictionaries) to refer to all situations in which people work together in a cooperative fashion. It’s a process. Not only is it not limited to conflict resolution, but it’s unlikely to resolve serious conflicts, since serious conflicts generally arise when people lose their ability to cooperate.

Consensus isn’t a process. It’s a result — general agreement, or more formally, a state of being in which everyone involved agrees to support a decision, regardless of what they personally would consider to have been ideal. The best consensus decisions start with collaboration, but collaboration isn’t required.

What is required is a shared desire to find some way to move forward.

Consensus isn’t the only way to make business decisions. It isn’t suited to all situations, or even most situations. It’s time-consuming, and is in consequence expensive. For engineering situations it’s risky, because the process of compromise required for consensus easily leads to design inconsistencies, and those, in turn, lead to kludges, deep in the heart of the architecture.

Use consensus when what matters, more than anything else, is buy-in — commitment to the course of action chosen by the organization. Use other methods for other circumstances.

Take product design as an example. A very good way to design products is to put a product manager in charge of a small team, consisting of experts from marketing, design, engineering, manufacturing, and cost-accounting. This gives you your best shot at creating a well-built product that’s easy to manufacture and appealing to customers.

Except that it’s never that easy. The most marketable product might be hard to manufacture. The best engineering might have too little market appeal, or be too hard to manufacture as well. What’s easiest to manufacture could require the elimination of highly desirable product features.

And what everyone else wants to build might end up costing too much, thinning margins to unacceptable levels.

Every member of the design team will have to make … that’s right … compromises. Which means that with all the best of intentions, your attempt to avoid the expense of consensus has simply shifted the responsibility for arriving at consensus to a different group of people. You don’t seriously think that having everyone make their case to the product manager, who then makes all of the decisions, will work, do you?

So here’s your guideline when it comes to design decisions of any kind: Unless one person knows enough to design the entire entity, whatever it is, charter a design team. Keep it small — no more than five people; three is better. Choose people who already know and trust each other’s judgment. Failing that, choose people who you know can work well with others.

Who can, that is, collaborate to arrive at consensus.