What is technology churn?
Technology Churn, as we are using it here, is the rate of change in release, adoption and abandonment of technologies.
A long way from just having the <script> tag and jQuery isn’t it?
As frameworks have come into more common use the problems for which they are being used become the more common. You can now find them in large single page web applications and small brochure-ware sites. This framework churn is not just affecting the large web applications anymore. Things that were once simple are becoming more complex. This, in turn, increases framework proliferation and entrenchment. Having choice is a good thing, but too much choice leads to fragmentation.
The lines are getting muddled between what is the right way to go and what is just a shiny new thing. The result is churn as sites are being developed and redeveloped using new frameworks and tools in tighter and tighter iterations.
The reasonable question would be: why not pick one and stick with it?
This left a lot of sites built around tools that were no longer getting the development push to keep current. As more developers used jQuery, jQuery had more development and these other libraries faded faster. You do not want to be the developer keeping a site alive using tools nobody is supporting any longer. As the browser ecosystem itself is in an increasing pace of iteration your tooling must stay current. These sites, then, stagnate as it becomes more difficult to modernize, the browser base then modernizes beyond them and most importantly, less new developers understand their frameworks and tooling.
Part of the allure of the shiny new thing is that it may become the actual thing and should you not have some investment in it you may be left behind.
The situation in 2016
Technology churn and its impact on your business
The business problem is the impact this shakeout period is going to have on the codebases of companies for years to come. Developers come and go, but the foundational choices they make for your company’s technology systems have lasting effects.
Legacy in regards to the web is unlike legacy as typically defined in software; we consider web legacy as between 3-8 years old. Often web systems are built by teams that have since moved on, but leaving sites that still need to be updated and maintained. Too often the “shiny new thing” becomes legacy software, which becomes more difficult to maintain as the foundational underpinnings are abandoned. Fewer developers are familiar with those systems and therefore the opportunities for and cost of the maintenance become crippling. Adding new and needed features and functionality becomes prohibitively difficult and expensive.
In our roles as Virtual CTOs, Web Developers and especially as technical mediators, we are exposed to both sides to this debate. The fear of choosing a platform destined to quickly become outdated verses the need to provide tangible and cost-effective value with the delivered product. Websites requiring constant re-writing to keep up with the new new thing do not provide good value for the business. Neither do systems which become too difficult to maintain after a short window.
2016 will be a hard year to make these choices.
- Does this add appreciable value to the site and its users?
- Does it solve your problems of today, not the expected problems of tomorrow?
- Can you afford to replace this in a year?
- Can you wait longer before initiating or redeveloping?
If you have to use a rich client-side framework, try to minimize disruption if the site must eventually be moved to a new system. Rather than write a large single page application in a framework, break the solution down into multiple pages and try to isolate the framework components to only the necessary areas.
Most importantly, know what you are getting into from a long term support and maintenance standpoint.
Development teams, and the shiny new thing, can come and go, but this software ultimately becomes your responsibility to keep going, years after it ceases to use the Most Favored Framework of its day.