J Cole Morrison
J Cole Morrison

J Cole Morrison

Startup Engineering, former Techstars Hackstar and AWS Solutions Architect. Based out of Sacramento, California.

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

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

Practical and Professional Devops with AWS, Docker and Node.js Video Series
  • • Full Series with 80+ Videos
  • Zero to Everything Setup
  • Full Development Environment for Teams
  • Seamless Continuous Deployment Pipeline
  • Reusable CloudFormation Template
  • Service Oriented, Database Ready
  • Complete Conceptual Explanations
  • FOR PROFESSIONAL AND PRODUCTION USE!
J Cole Morrison

J Cole Morrison

http://start.jcolemorrison.com

Startup Engineering, former Techstars Hackstar and AWS Solutions Architect. Based out of Sacramento, California.

J Cole Morrison

J Cole Morrison

Startup Engineering, former Techstars Hackstar and AWS Solutions Architect. Based out of Sacramento, California.

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