As the environments in which we live and work become augmented by networked information systems, it behooves us to learn something about how those systems work — and about how to work those systems. “But I don’t need to know how my car works,” you say, “why do I need to know how my computer works?” You don’t. That’s the wrong analogy.

Our civilization’s enabling infrastructure exists only because we’ve created many different kinds of specialized knowledge, and because we — the knowers and practitioners of these specialties — participate in networks of exchange. It’s a good thing that most people don’t need to know how to repair faulty disc brakes or laptop hard drives.

It would be really bad, though, if most people didn’t know anything about the physical laws that keep the car’s rubber on the road, or the social laws that govern traffic intersections. That’s the level at which people need to know about networked information systems.

A lot of what the creators of those systems know isn’t at that level. A few things are, though, and I’ve been working up a list of things creators know that users could and arguably should know. From time to time I think of adding another item to the list. So far, though, everything that comes to mind is already, in some essential form, on the list.

The latest example is a rule known as Don’t Repeat Yourself. Programmers invoke DRY when they squeeze redundancy out of code or data. Where does the duplication come from? Information systems, like human cultures, evolve by copying parts of themselves — and of one another — and then by modifying the copies. That’s the natural and healthy trend toward diversity. But systems and cultures also evolve by converging on a core of shared commonality. That’s a natural and healthy countervailing trend. The most successful copies need to merge, at the right level of generality, with the core.

These two styles are in dynamic tension. On the C2 wiki, where Ward Cunningham has for many years hosted a conversation about the core principles that govern information systems, the topics DontRepeatYourself and PrematureGeneralization express that tension. It’s good to DRY things out, but bad to generalize prematurely.

Does that rule belong on the list? Maybe. I wish programmers weren’t the only ones feeling and responding to the tension between DRY and WET1. Anyone who aims to automate work, for example, needs to learn how to walk the WET/DRY tightrope.

But maybe wringing out redundancy isn’t the essence of DRY. Here’s what the noted software pragmatist Andrew Hunt says on the DontRepeatYourself wiki page:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

That’s an assertion about the value of authority, not the problem of duplication. And the first rule on my list already says: “Be the authoritative source for your own stuff.” In the context of the elmcity project, which is the incubator for the list, that means if you’re promoting a calendar event online, you ought to publish a single authoritative version of that calendar entry to a system that’s accountable to you. You shouldn’t have to repeat yourself by making copies of the calendar entry in systems that aren’t accountable to you.

When you’re the authoritative source for some set of facts, and when you inject those facts into the networked information system called the web, Don’t Repeat Yourself is a great principle to keep in mind. I’ll be delighted if you do. But it’s the underlying core principle of authority that I most want you to embrace. When you’re the authoritative source for your own stuff, you’ll naturally tend to stay DRY.


1 There’s no agreed-up expansion of DRY’s opposite, WET. Here’s mine: Watch, Emulate, Transcend.