On project dependencies
No matter what we do at some point in our careers as developers we all face the dilemma of introducing external dependencies to our projects. We are pretty sure that you, dear reader, have faced it too. If you did not, you will, we promise you, it’s as inevitable as the chickenpox.
There are various reasons to rely on third-party code. It could be because you want to measure your app adoption and you don’t want to waste time writing the measurement layer. Or because you have to introduce a functionality that deals with a matter that you don’t quite have the experience with. Or because your dev buddies told you about that library that is going to sort out most of the existing issues that your app has. Or because that library had been there since the day you started working on the project in the first place. Or simply because you don’t want to deal with some of the basics every time you start a new app. Everybody hates boilerplate, right?
All of the above are valid reasons, but…
Picking a dependency can be a tricky process
There are few things that you should take into consideration:
- Acknowledge the fact that adding a dependency makes it your code. Even if you have not authored it, it ships with your app, it’s part of your app’s workflows, some logic relies on it, so it’s your code too. You are responsible to maintain it (even if that maintenance goes as much as keeping the dependency updated).
- Make an informed decision. A google search might yield you a handful of options. How would you choose which one to pick? We would check the history of the dependency. It’s easy for most of the public libraries — just check the project on github. Look for things like how frequently the project gets updated. It might not seem important at first sight, since it does the job, right? But imagine it being a UI library that has no support for the next iPhone which is going to have two notches (figuratively speaking, you’ll see lots of that). Can you afford losing clients by waiting for the authors to update their libs 2–3 weeks (or more) after the device is on the market? It happens to the best apps on the AppStore, for real, it may happen to you too. We’d render suspicious a project that has no release in the last 3 to 6 months.
- Take a look at the list of the known issues of that dependency, the less they are, the better. Check the tone of the discussions, the age of the topics. Try to get a sense of how fast the bugs are getting resolved. You don’t want your app to host a bug that hasn’t been fixed in the past 2 years. You also don’t want to deal with people who are rude towards the bug reporters.
- Check the quality of the code. Some libraries start as side projects or are being used to demo the skills of their developers. Once in awhile a library becomes unmaintained because of various reasons — the author might get engaged into something else, or could simply lose his will to maintain the library. Depending on how deep the integration with your project is, dealing with such problems could be unpleasant. This can put you to a position to fork the project and to continue maintaining it yourself. It’s always better to know that you will enjoy doing so (and that you understand what’s going on to a degree that you can maintain it, of course). Or it may shift your attention from introducing new functionality to your apps to figuring out a suitable replacement.
- Consider treating the company-backed libraries equally to the single developer-driven ones. Most of the times, companies are looking at the libraries from the same perspective as the single developers — as a tool to promote themselves. Some companies make money out of their libraries. Every now and then a company gets acquired and changes its vision in consequence. This can also put you in a position to figure out a replacement. And if such a thing is at the foundation of your data stack, it could be a pain.
- Checking the capabilities of the library and figure out how would you utilise them. Would you use 1/10th of it’s capabilities? Do you really, really, really need to take the next 90% with your app for the price of these 10%. You may end up getting inspired to code these 10% of functionality alone.
- Make sure that you are aware of the fact that third-party code also has bugs that can be critical sometimes. This means that you have to be prepared for a situation where you have to deal with a third-party bugfix in the middle of your new feature development process. This could affect how you manage the code of your app, it may also have an impact on the testing workflows and so on.
So what, avoid dependencies?
No, not really. There’s a lot of great stuff out there that you can’t simply ignore. In fact it’ll be expected from you to know how to deal with some of the most popular libraries.
A library with some community around it (that also passes the checklist above) is what we usually consider a good candidate to get added to our projects.
A library that is well-maintained by a single dev can also be a good option. Find that guy on Twitter, drop him a line, tell him that you are interested in what he’s doing. Ask him about his plans for the project, and who knows, you may discover a new dev buddy.
Try to avoid leaning on third-party code for small, utility-like stuff. You know, things like the next fancy UICollectionView layout for example. Or that fancy String extension that’s wrapped in a pod. Also, do you really need all of the features of that third-party image loading library? Or that JSON-to-object library that’s been in your project for the past 3 years. You will learn so much if you code and manage these bits of your apps on your own, we promise you.
At the end of the day it’s you who’s in the driving seat of your app. It’s you who decides how much control over its features you want to have. It’s up to you to choose where to steer it at, and how to manage it. We just hope that the above may help you in the process of deciding on your dependencies next time.
