J Cole Morrison
J Cole Morrison

J Cole Morrison

Lead Engineer @Fieldboom, former Techstars Hackstar, AWS Solutions Architect, and Headmaster at awsdevops.io

Practical and Professional Devops with AWS, Docker, and Node.js

"We really don't need to upgrade that package right now.."

Posted by J Cole Morrison on .

"We really don't need to upgrade that package right now.."

Posted by J Cole Morrison on .

We don't need to upgrade our frameworks and packages every single time they change. Even if the update has a whole army of shiny new things.

And I'm serious, we really don't. I'm particularly referencing the Javascript world and even more specifically front end development. Both configuration and tooling as well as core frameworks themselves.

Here's the problem:

In my experience, these decisions seem to always get thrown down in evaluation as

benefit vs breaking changes

When in reality it truly needs to be

benefit vs total cost to business and team

And by total cost I mean

a) side effects that we totally don't know about yet in other packages

b) side effects in our own custom packages

c) bugs that this new version may bring that aren't yet identified

d) time to configure and integrate the updated package/framework

e) time for everyone on the team to understand any new tools or syntax changes it may bring

Every time Babel or Webpack upgrades there seems to be a new way to write something that already works. And somehow what was already working is just plain wrong as a result.

Would you like to tear a wrecking ball through your code? Take your redux react application and force Immutable.js onto it. That'll make your day.

immutable panda...

f) time spent code reviewing the changes

g) the opportunity cost of everything above that could be spent hardening the application's core logic, creating new features and wiping out bugs.

Seriously. How many bugs are in the back log? Is the UI locked down? Is everything tested? Have we even caught up to all of the syntax/semantic changes from the past few updates?

OBVIOUSLY, this doesn't mean never upgrade. When do we upgrade?

When the benefits > total cost to business and team

Now of course there's the FLIP side to this entirely:

Is the team taking 10x as long to accomplish something because the entire framework is antiquated and barely compatible with ANYTHING? Okay, well we've answered the question on whether or not to upgrade. And what would the upgrade look like? A couple weeks of work for a huge boost in productivity? Do it.

Is there a huge security patch that the framework maintainers are declaring as a must? See if your app is vulnerable with respect to that issue and change it if needed.


Last thought. If we're walking down a road to a destination, and we stop to buy new shoes and clothes - are we making progress to the destination?


More from the blog

J Cole Morrison

J Cole Morrison

http://start.jcolemorrison.com

Lead Engineer @Fieldboom, former Techstars Hackstar, AWS Solutions Architect, and Headmaster at awsdevops.io

J Cole Morrison

J Cole Morrison

Lead Engineer @Fieldboom, former Techstars Hackstar, AWS Solutions Architect, and Headmaster at awsdevops.io

Practical and Professional Devops with AWS, Docker, and Node.js

Free 10 Part Video Series on Docker and AWS

The Hitchhiker's VIDEO Guide to AWS ECS and Docker The Hitchhiker's VIDEO Guide to AWS ECS and Docker

An Exploration of Deploying Docker based Apps and Services to AWS EC2 Container Service.

Checkout the FREE 10 Part Video Series