Imagine you’re a marketing agency for a moment. Now quick: how many of your clients’ websites are based on obsolete technology? What about the three clients you just signed? Are you inheriting a mess? Are you burning the sites to the ground and replacing them with new technology? When will that technology be obsolete?
What does it even mean to be obsolete? One thing is immediately obvious: obsolescence is not a binary proposition. A given technology does not exist in one of two states: “current” or “obsolete”. It’s a continuum. An ASP.NET website built on MVC 4 may be state-of-the-art as I write this, but does that make an MVC 3 website obsolete? Certainly not. And in N months, when Microsoft is shipping MVC 5, that won’t make your MVC 4 site obsolete either. More obsolete, maybe, but a far cry from the death knell of complete obsolescence.
So now that we’ve got that out of the way, let’s talk about the factors that comprise obsolescence. Time is certainly a factor, but far from the only (or even most important) one. A far more important factor is support: from the company (if, indeed, the technology is produced by a company), from the community, from your own employees, from your contractors, and from the pool of available talent for hire. If you factor support into the equation, then suddenly you’ll notice that the “age” of a technology has a sweet spot. Too old, and it’s been forgotten, surpassed, put to pasture. Too new, and it’s too buggy, or no one understands it yet. To complicate matters, this curve, and thus the elusive sweet spot, is different for every technology. Some technologies, for myriad reasons, are adopted or understood more quickly. Others still fall out of favor and decay at different rates.
Let’s step back from obsolescence for a minute, and think like a bean-counter. What do the bean-counters care about? Cost. So we can think of a given technology having a cost. Like obsolescence, the cost of a technology is a many-headed hydra of complexity. To get a handle on the beast, let’s fix one variable in place: the work itself. That is, let’s pick one bit of work, a specific website, say, and think about how much it costs to implement in different technologies. Some technologies are better at some problems, of course, so let’s try to even out the differences somewhat by saying the website is BIG. It’s got interactive elements, animations, a database-driven CMS, and interfaces to multiple external web services. Everything but the kitchen sink. Of course, nowadays, such a website cannot reasonably rely on one technology only. The server-side/client-side split alone necessitates at least two distinct technologies (neglecting, for now, solutions like Java applets or Flash applications).
So how much is it going to cost us to implement our mammoth website? A lot more than just technology goes into a website, of course. Project management, account management, creative, image production, copywriting, and QA, to name the obvious ones. For the purposes of this article, I’m going to assume those costs are fixed. That is, of course, a ridiculous assumption, but I’ll leave the calculations of those costs to my colleagues who specialize in those aspects. Before I dismiss those efforts as fixed, however, I feel obligated to point out one thing: the choice of technology can drastically effect content production. For example, content production will cost significantly less for a website with a solid CMS in place.
So, back to the cost calculation. Let’s ignore the cost of hosting, and other services like third-party search engines, and SEO. With the exception of SEO (which can be quite costly depending on the market penetration you’re after), these costs are usually insignificant compared to the costs I’m about to discuss. Also, they are relatively invariant to the choice of technology. That leaves us with three components of cost: the tools required to build the site, the associated technology licensing, and labor. Once again, I’m going to remove some complexity by ignoring the cost of tools. For two reasons: the cost of tools is usually insignificant compared to labor, and tools (if purchased thoughtfully) are re-used for many projects. I’m also going to ignore the cost of licensing, because that is also usually insignificant compared to labor costs. These dismissals, of course, will enrage the F/OSS crowd, who love to trumpet the benefits of completely free tools and technology. To them I say this: write your own blog post, and show me how the cost of tools and licensing are more than a drop in the bucket compared to labor costs. I’m all ears.
So now we’re down to one variable: labor. Makes it sound easy, doesn’t it? Not so fast, cowboy. It’s time to loop back to the topic of this article: obsolescence. Let’s consider the obvious, first. Remember the “sweet spot” we talked about in terms of a technology being not too old, or too new, but just right? If you pick a technology that’s in that sweet spot, you will minimize the cost of labor…or will you? Here’s where it gets more complicated, and sets the stage for the next actor in our madcap play: longevity. There are websites that are “throwaway”. For example, a website for a one-time event. It lives for a few months, or maybe even a year, then it’s taken down. For that website, the so-called “sweet spot” doesn’t look too sweet. The fact that that technology is “just right” doesn’t necessarily mean it’s cheap. Often, the “just right” technology is in demand, driving up the cost of engineers skilled in that technology. On the other hand, it might be very popular, meaning there’s a large pool of engineers with that skill, which works in the other direction by driving salaries down. It’s a delicate balance, but the upshot is the “just right” technology may be significantly more expensive than an aging technology. For a throwaway website, picking the cheapest technology is often wise, and that may mean avoiding the sweet spot.
However, in my experience, most websites are not throwaway. Clients expect them to last a minimum of three years, sometimes as much as five or more. Now the equation is complicated by the issue of maintenance costs. This is where technologies that live in the sweet spot become more attractive. These technologies have a certain momentum that staves off obsolescence longer, thereby reducing maintenance costs.
Let’s look at some concrete examples. Technology platforms that have fared well include Java, PHP, and .NET. Java and .NET because a 300-pound gorilla put their weight behind them and got the ball rolling. PHP, in a way, was an answer to the 300-pound gorilla options. All three, though, live in the sweet spot: there is a vast support network, and a large pool of talented developers.
At the other end of the spectrum, who would write a website these days using C/CGI? No one in their right mind! Now, don’t get me wrong, I’m not harshing on C (and I am certainly not calling the language itself obsolete). C is very much in the sweet spot for embedded design and (to a lesser extent) systems programming. But for web platforms, it is all but dead. Another good example (which I’m sure will generate some debate) is Python. Python is a fantastic language, and is almost ubiquitous among scientific and research applications. There are Python-based web servers and web frameworks, but it was a matter of too little too late to make serious inroads as a popular web platform, and it lost out in a big way to its F/OSS rivals PHP and Ruby/RoR. And perhaps the saddest fall from glory: Perl. Once a huge player in web platforms, its web empire has long since crumbled.
Then, of course, there is Ruby on Rails, which I find much harder to classify. If you look at pure statistics, its market share is minuscule (one report even put it three tenths of a percent below Perl!). However, thanks to a rabid developer community, and an almost laser-like focus on web development, Ruby on Rails has become a very safe and capable platform on which to build websites. I’m tempted to call it the exception to the thesis of this article, but I am not a RoR developer, so I will leave this to others to debate.
While I am loathe to introduce yet another complexity, I would be remiss not to mention that these technologies I’m referring to cannot be considered monolithic. I’ll take .NET, since I am most familiar with it. One could easily argue that a website built on .NET 1.1 is indeed obsolete, while one built on .NET 4.5 is quite current. So this brings another consideration to the table: how easy is it to keep a given website current within the technology stack? Again, I’ll stick with .NET as an example since it’s my area of expertise. I’ve found that the cost of keeping .NET websites current is very low. Microsoft has done a great job of maintaining backwards-compatibility with each release of the .NET platform, reducing it to a matter of discipline to keep websites up-to-date. A lot of this is due to .NET being an extremely well-engineered platform from the start, as well as learning a lot from Java’s mistakes (this is not a criticism of Java: it blazed the way so that others could follow).
However, before I start sounding like a wild-eyed Microsoft zealot, the actual version of .NET is not the only thing that makes up the architecture of a website. A great example is the split between a WebForms-based site and a MVC-based site. It is excruciatingly painful to “update” a WebForms-based site to an MVC-based site. (I put “update” in quotes because some would argue, reasonably, that MVC does not represent an improvement over WebForms, just a different approach.) It has also been very painful to move from MVC 1 to MVC 2 (Microsoft learned their lesson there, though: going from 2 to 3 is very easy, as is going from 3 to 4). Another fly in the ointment (and my current hobgoblin) is the choice of CMS. For example, we have a site that we maintained that’s based on an an ancient version of DotNetNuke. I wouldn’t say that DotNetNuke is in the sweet spot, exactly, but it’s not far off of it. But that ancient version? Painful beyond measure.
Originally posted March 1st, 2016.
