Build vs. buy? More like, build *and* buy, amirite?

Look, I’m probably feeling a little salty because of some recent bad experiences with JavaScript.

I like JavaScript as a language, but when I think of what gets put into packages in the npm ecosystem, I’m reminded of Jeff Goldblum’s character in the 1993 Jurassic Park films who said:

Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.

For example, there are tens of packages on npm that give you a noop function. There are entire packages that make it so you don’t have to write: () => {}. Not worth a package.

With how easy it is to make packages, a tangled web of dependencies is created. Developers find this appealing because you can get so much functionality for “free.”

Until those things you depend on change. And change they will.

For seemingly arbitrary reasons.

You have to account for both sides of the balance, the assets and the liabilities. When you take on a dependency, you’re taking on its release schedule.

Joel Spolsky was on to something in his In Defense of Not-Invented-Here Syndrome.

As I get older, I’m really shifting towards not using packages I didn’t write for my business’s core competencies. The short-term gains aren’t worth the control of my product that I give up.


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.