The real cost of all those JavaScript packages

Or all those Ruby gems or Python whatever-you-call-thems.

Open source tooling has amazing packages right at your finger tips for solving that problem you’re working on today.

But every thing you pull into your app is something that you’re coupled to. They become part of your release cycle.

When you pull in a package, you pull in its maintenance schedule. Or you’re starting a ticking time bomb for when that package is no longer supported.

If you don’t stay on top of them, you could find yourself in a situation similar to GitHub when early in their life they had to hire an entire team of developers to backport security fixes into Rails 2.0 because they didn’t stay on top of their dependencies.

If you take that approach, you are taking significant leverage against your future ability to deliver quickly.

It’s not hard to increment a few versions here or there, so stay on top of it.

“But if we do that, we’ll never ship anything.”

That line gets trotted out as a reason to not do a lot of sensible things, but let’s go with it for a moment.

Fine. Don’t pull in so many packages.

Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!

Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.