A young developer newly embedded in the enthusiast programmer community could be forgiven for believing certain truths to be self-evident: that most people use Apple computers. That most websites are written in Ruby, NodeJS or Java. That most tech jobs are at Internet app startups.
The truth is little different:
- About 90% of personal computers run Microsoft Windows.
- 80% of websites are written in PHP (WordPress alone now accounts for 27% of all websites).
- Relatively speaking, hardly any programmers are working at Internet app startups.
Not everyone works for VC-backed app-focused startup. In fact by volume, globally, hardly anyone works for a VC-backed app-focused startup.
— Jen Simmons (@jensimmons) December 23, 2016
The other day I got to thinking about the enduring dominance of PHP and Windows in their respective domains; and what, if any, attributes they might share in common to explain their success.
At first the two seem almost nothing alike. Certainly they come from two very different backgrounds: Windows, with the unimaginable corporate weight of Microsoft behind it; PHP, starting out with no corporate backing but with an endless swarm of eager novices tinkering and showing their friends.
But as I thought about it more, I realized that these two products do share one thing in common: an almost maniacal focus on backwards compatibility.
As I am writing this, the PHP community is making the slow jump to version 7.0, straight from version 5.6 (it’s a long story). And despite the introduction in 7.0 of some major changes to the language, there is none of the trauma of, say, the Python 3 transition.
I recently made the PHP 7 switch on one of my own site; it was a matter of selecting a different radio button and hitting “Submit”. My site uses dozens of plug-ins from different authors, but I haven’t seen any incompatibilities crop up.
And then there is Windows, whose dedication to seemingly eternal backward compatibility is legendary. There is even a blog dedicated to the topic.
This focus on remaining compatible with software from bygone eras can seem foolish, or worse, from a modern developer’s perspective. Or from a business perspective, for that matter. After all, isn’t it true that the right thing to do is to carefully manage our user’s expectations, and know when to say “no”? Isn’t Microsoft shooting themselves in the foot by doggedly forcing themselves to carry forward this vast boulder of outmoded functionality? Isn’t that what Apple gets right, that Microsoft got wrong all these years?
But then you visit the control room of a plumbing fixture manufacturing plant where the computers are all running a Windows-based control program purpose-built for just this one industry, an application which had its last major update in the Windows 95 era, costs $10,000 a seat, and which has sold fewer than a thousand licenses over its entire lifetime.
And then you multiply that one example by 100,000 or a million different niche verticals. Ugly little specialty applications, built on APIs long consigned to the deprecation bin of history, still chugging away on Windows XP boxes, Windows 7 boxes, and now Windows 10 boxes.
What do Windows and PHP have in common? They are both snowballs that have been slowly rolled over decades, and which have never surrendered a single ounce of the snow (or leaves, dirt, gravel, lost mittens…) that they’ve accumulated.
They are clunky, idiosyncratic, slow to evolve… and dominant. Despite the concerted efforts of numerous challengers furiously trying to chip away at their position, for years on end.
I don’t think that there is any kind of universally-applicable lesson here. Certainly I’m not suggesting that we all make backwards-compatibility our top priority.
But I feel like there’s something worth learning here. While it can be tremendously exciting and freeing to “move fast and break things”, a slowly-built institution can (sometimes) have a momentum and a longevity that would be the enviable by most flash-in-the-pan “disruptive” technologies.
Respect the power of the snowball. It doesn’t have to be a snowball of code, either. It could be a 25-year-old editor, a carefully-tended mailing list (), a user community, or a personal body of work.
If nothing else, don’t underestimate a snowball you’ve set out to “disrupt”. If you stand directly in front of it, you’re more likely to get flattened… and then, probably absorbed. Think about how you can leverage the momentum and weight of the snowball instead.
What kind of snowball are you building?
P.S. This post started its life as a message to my SIGAVDI mailing list that grew a little long for an email. If you found it interesting, you might enjoy
Comments are closed.