Your web framework is a risky dependency


Provocative title, no? How could something like Ruby on Rails, Laravel, CakePHP, et al be a risk when it provides so much value? That, my friend, is short term thinking. You’re absolutely right, in the short term these frameworks have a lot of value. But ask yourself this. Given the choice, would you step in and work on Rails 4, Laravel 4, CakePHP 2 (or 1!)? What happens when the new version of your preferred framework goes EOL (End Of Life)?

And therein lies the risk. And I hear you, part of maintaining software is upgrading it through the new versions of the framework. There’s no doubt that maintenance is a fact of life for software projects, but there can be more or less maintenance required and any time or money spent on maintenance is time and money not spent on the velocity of the project itself.

So lets break down the specifics of the long term risk and then talk about what we can do to help minimize them.

Developers don’t find you attractive

I’ve seen this many times, a company is looking for talent for a specific framework and they’re having trouble finding it. In one case the company ended up flying an expensive consultant out from the coast for the expertise.

What inevitably happens is the company will eventually agree to the rewrite. Rewrites are always inherently risky. And if the rewrite is in the latest version of the same framework? Who says the long term risk has significantly changed? Would you consider a great value proposition to potentially rewrite the software every 5-7 years?

The entire stack can become obsolete

What happens when newer versions of the programming language are incompatible with your framework of choice? For example, Rails 4.0 doesn’t support anything newer than Ruby 2.0 which hasn’t received security patches for years now. What happens when modern OS’s no longer support the old framework or its dependencies? When you’re forced to run an Operating System that’s no longer supported and therefore doesn’t receive security patches?

It’s a scary proposition to be that insecure, the University of California recently paid over $1 million USD to hackers that got into their servers and then encrypted the drive. For many small to medium-sized companies, this is a death knell. The chances of recovering from this are so slim they may as well not exist.

That’s not even taking into account the type of data being kept by the software system. What if it’s PII (Personally Identifiable Information), or even worse PHI (Protected Health Information). Not only are you potentially running the risk of harming your own customers, the fines themselves may be every bit as deadly as the hackers encrypting your server’s drive.

These are the sorts of risks that you get away with until you don’t, and once you don’t you probably won’t recover from it.


So how do we avoid the pitfalls and the risks related to your web framework of choice? Here are my recommendations.

Understand you’re hopping on a rat wheel

If you opt into one of these web frameworks, it means you’re going to be updating your software to be compatible with the newer version in perpetuity. Maintenance no longer just includes fixing bugs or making functional improvements, it now means upgrading the framework itself on a regular basis.

To fully understand what that can mean, consider Laravel’s release history. Laravel releases new versions with incompatible updates every 6 months, so twice a year.

Or Ruby on Rails release history. They release a new version with incompatible updates once a year.

These projects will continue supporting older versions for a while after the newer versions come out (for 1-3 years typically), but having to skip versions during an upgrade is a lot harder so it’s better to keep up with the newer versions.

Choose frameworks that respect backwards compatibility

This seems obvious, but lets talk about it anyway. If you built an core app 3 years ago it will still run on the new version about to be released ( 5) and if there **are** changes they’ll tend to be small.

The reason for this is that Microsoft has a financial interest in backwards compatibility. In general you can upgrade to the latest version with little to no losses in functionality. This means you can remain secure with a much smaller long term maintenance cost.

Consider release cycle/change density balance

When choosing a framework, consider both the length of the release cycle and the number of breaking changes that tend to happen in those releases. For example, while Laravel does create a new release every 6 months, the new releases don’t tend to change more than 1 or 2 specific things. Depending on what those changes are, you may even be able to get away with the upgrade not breaking anything for your application.

On the flip side, a framework that releases every 3 years may have more backwards incompatible changes (although it’s not guaranteed). A good example of this is CakePHP 2 vs CakePHP 3.

Consider the maturity of the project

Early on in a frameworks life new releases may drastically change things in the framework as they figure out what works and what doesn’t. Once they’ve matured, the rate of change will slow down and upgrading between versions becomes easier.


We as developers must make sure those paying for the work understand they’re opting into long-term maintenance. This may sound obvious but many non-technical people treat it like they would their concrete porch; Once it’s done there’s very little maintenance needed to continue safely using said porch.

This is especially true for freelance and contract developers. Often you’ll get a small company that pays for the initial work. The developer disappears and then the site sits for years with nothing done to it because it’s working. Fast forward a bit and they decide they want a new feature, only they discover it’s a lot harder to find someone willing to work on it than it was finding someone to build it.

If you are a freelance or contract developer you MUST communicate this need or you’re doing your clients a disservice.


If there’s one thing you take away from this article, I hope it’s this:

Maintenance for projects using most of these web frameworks must be explicitly understood as including upgrading to the newer versions as they come out, and this long term need should be considered when evaluating which web framework to use.

About the author

Michael Reiland

Add comment

Recent Posts

Recent Comments