This essay is about the use of platforms within software development organizations.
Whenever I hear someone talk about building a new software platform for their organization I am instantly skeptical. My reaction has nothing to do with lack of confidence in the speaker. It is just that most platforms are failures. The problem is that the supply of frameworks, platforms and other reusable code projects far exceeds demand. More specifically, there are many, many people who would just love to create the platform that everyone else uses, while the market just wants one platform. The poster child for platform wannabes is Microsoft, which won the first rounds of the desktop operating system game and now owns a huge percentage of that market. Some more recent hopefuls are Facebook, Ning and Google Maps. Goeffry Moore, in The Gorilla Game, does a great job of explaining the risks and rewards of trying to be a platform.
But not all platforms are created with the goal of being the gorilla. Large companies tend to breed platforms like rabbits and open source frameworks grow like weeds. At one point in 2004, it got so bad that someone created a framework-framework, the Keel Framework. Happily, it didn’t last long (see bile blog’s writeup if you don’t mind strong language). There is so much platform proliferation that simple economic factors do not suffice as an explanation.
I think the ultimate cause of platform proliferation is simply that software developers love to build platforms. For many, building a platform represents the pinnacle of technical achievement. As I’ve said elsewhere on this blog, creative technical people are in this business because they like to make things that are valued by others. What can be more self-affirming than creating something that your peers use to build even better things? And other aspiring platform developers often reinforce this feeling by buying into a particular platform ideaology. For instance, there were people who actually used the Keel framework-framework. Go figure.
While in principal, this tendency toward platforms is neither good nor bad, in practice it can lead to disastrous results. This is because architectural decisions regarding platform choices stay with you for a long time and are very difficult to reverse. Here are some patterns of failure that are particularly damaging:
- You don’t need it. Platforms are expensive and complex. Often the disadvantages of using or creating a re-usable code framework far outweigh the rewards. Unfortunately once you make a decision, it takes a long time to find out whether the decision was a good one or a bad one.
- You made it yourself when you should have used someone else’s. This is so common that there is an acronym for it NIH (Not Invented Here).
- You chose the wrong one. Everyone who wants to use a platform has their favorite choice among many. The selection of a platform is based on a number of factors, some of which are only partially related to the business problem at hand. For instance, don’t choose a platform if you can’t find good developers for it.
In any software development organization, there is a constant tension around where to put your money; in the platform or the application. Software developers love to make platforms so there is always plenty of pressure to either use or make a new platform. Yet the selection of a platform is fraught with peril. As the ancient knight said in Indiana Jones and the Last Crusade, “choose wisely”.
Later I will write about specific examples of platform peril from my career.