Save your future self from broken apps by asking these questions BEFORE adding a third-party framework to your app

I wanted to rant about how adding third-party frameworks to our code has become the default and how bad that is and how we’re all going to have to deal with broken code…but I found a more productive way to communicate the same thing. Please – for your own sake – consider all the costs associated with adding a third-party dependency to your app before you reach for the latest shiny new tool. You can use these questions to get started, but they’re by no means exhaustive.

Before adding a third-party framework to your app, ask yourself…

How much effort does it save me?

  • How much pain does it take away?
  • How many lines of code does it save me?
  • How much effort will I have to put into it to make it work for me?

Is it secure?

How many people are using it?

  • Is there a good community around the project that can answer my questions when they inevitably come up?
  • How many are asking questions about it?
  • How many are answering questions about it?

Is it well maintained?

  • Will it continue to be maintained?
  • When a new version of the platform or developer tool is released, is the framework still likely to work?
  • What if it stops working on a new version of the platform?
  • How many people will care?
  • Will they do something about it?
  • Will I?

Is it well documented?

  • Is it easy to understand how to use it?
  • Is there good documentation in the code?
  • Is there good documentation on the website?

Is there good sample code?

  • Does the sample code show me everything I need to do with the framework?
  • If I want to do something other than what’s in the provided sample code, will it be easy to do?

Is it well supported?

  • Will it continue to be supported?
  • What if it stops being supported?
  • Can I get by without support?

How many contributors are there?

  • If the main contributors lose interest, who’s going to maintain it?
  • Does someone on my team want to?
  • Do I want to?

Is it stable?

  • Does it have automated tests that prove that it’s stable?
  • Are the tests passing right now?
  • Will they pass tomorrow?
  • Does it have automated builds?
  • How often do the automated builds fail?

Does the project follow good coding practices?

  • Does it follow proper naming conventions?
  • Does it use idiomatic code for the language and platform?

Do I understand the code in it, at least at a high level?

  • Would I be able to fix issues that come up?
  • Would I be able to add features I need that are missing?

Will I be able to debug it?

  • When I find a bug in my app, will I be able to figure out where it is?
  • Will I be able to figure out whether I’m using the framework incorrectly or the framework has a bug?
  • When I’m not sure, is there somewhere I can ask?
  • Is it likely I’ll get an answer?
  • If the bug is in the framework, will someone fix it?
  • If nobody does, am I willing and able?

When I update to the latest version of the framework in 3 months, will my app break?

  • If it does, will someone else fix it?
  • If they don’t, how much time am I willing to spend fixing it?

How much weight will it add to my app binary?

  • Will it degrade my user experience by making the initial app download significantly larger?

Does it have features I don’t need?

  • How many?
  • How big are those features?
  • Will they cause unnecessary weight to be added to my app binary?
  • Will they get in the way of me using the rest of the framework?

Update Aug 6: Mark Strayer wrote in and suggested another great question:

  • How much pain am I looking at if I have to rip this out?

Update Aug 26: Lots of good comments from Twitter. Here are a few of the best:

Update Dec 4: Andrew Bancroft has written an article on the topic that categorizes some of these questions with some of his own. If you haven’t seen it yet, you should certainly read it.