Platforms and the rule of three

Back in my old gig, I wrote a feature-length story entitled “Top 20 IT Mistakes” and wrote a followup blog post in which I referenced the excellent Facts and Fallacies of Software Engineering by Robert Glass, writing:

The book contains 55 facts ranging from the people-specific (“Fact 1: The most important factor in software work is the quality of the programmers”) to more specific rules of thumb about the process (“Fact 21: For every 25 percent in problem complexity, there is a 100 percent increase in solution complexity”). There are also 10 fallacies (e.g. “Fallacy 3: Programming can and should be egoless”). Both the facts and the fallacies are organized in a uniquely readable way — each one is a self-contained unit (cross-referencing the others when appropriate) that is divided into “discussion” (an outline of the collected wisdom behind the fact or fallacy), “controversy” (a description of why it is controversial), “sources” (a discussion of the source material available on the subject), and “references” (a traditional bibliography for that particular fact or fallacy).

These days, I’m thinking more about platforms than avoiding IT mistakes, and Glass’ book has helped clarify my thinking once again. Recently, I was thinking about what made a technology a “platform” technology (particularly in the context of the Web 2.0 “web as platform” concept) and I had decided that the platform test was simple: if a piece of technology served two or more separate systems, then it’s a platform, so platform technologies should be designed to do that. With that in mind, I looked into Glass’ book again and this time, Fact 18 suggested that my minimum was one short:

There are two “rules of three” in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

This sort of language seems very particular to writing code libraries/modules for use inside an organization, but I think the thinking clearly extends to web services that are intended to be “platforms.” Glass goes on to say that the skill set and approach required in building reusable code (and therefore “platform” code in my mind) is unique:

It is no wonder that knowledgeable experts say it takes three times as long. It is also worth pointing out that, although most people are capable of thinking about problems in a generalized way, it still requires a different mindset from simply solving the problem at hand. Many advocate the use of particularly skilled, expert generalizers.

The second rule of thumb is about being sure that your reusable component really is generalized. It is not enough to show that it solves your problems at hand. It must solve some related problems, problems that may not have been so clearly in mind when the component was being developed. Once again, the number of three — try your component out in three settings — is arbitrary. My guess is that it represents a minimum constraint. That is, I would recommend trying your generalized component in at least three different applications before concluding that it truly is generalized.

Those three applications don’t have to be huge, of course, and not all companies even have three products, but the “rule of three” seems reasonable when you’re thinking about building platforms. Maybe you won’t build those three apps to leverage your platform immediately, but you better be thinking about what those three apps might be.