Happy Friday!

The great unpacking continues in our new home. It is a miracle that our kids haven't torn apart every box and scattered their contents everywhere. Then I was thinking back to a horrible move we had when we moved to Arkansas the first time.

The short version is that the movers packed us up in North Carolina, but didn't deliver our things for five months. It all worked out eventually, but my wife and I had to get a little creative about how we'd get by for so long.

This brings me to tools, libraries, and frameworks. How can I transition like that you might be asking? Well much like choosing a moving company, choosing a library or framework is often an irreversible choice.

I find too many teams rush to grab a new library to do even trivial things. In part they are taught this by the developer community and senior devs who say, "Don't re-invent the wheel," or "Someone already solved that for you." The problem is that when we use that library or framework it is usually deeply integrated in the code in a way that is impossible to remove.

Now there are ways to deal with this, but that isn't the point of this email. The point of this email is about awareness of what kind of technical decisions our teams make in pulling new libraries and frameworks in.

I could distill the decision down to two questions:

• Are we ready to treat this framework like our own code?

I wrote an article with more criteria to consider too if you want to read it.

Oh, do any of you have a story about when a framework or library wound up getting the better of your teams? Let me know!

Sincerely,

Ryan Latta