In his article “Code dependencies are the devil” developer Bill Sourour lays out the problem of of relying on third party libraries for development. In it he claims companies should be wary and careful when designing apps dependent on other external code that’s prone to significant change.
Now I’m not going to argue with the basic premise which is evidently true. Even more so coming from an veteran developer whose opinions I value. However there are some issues with his claims that are either beside the point or a bit too broad. I’m going to address some of them here.
Sourour gives the example of Parse a once promising startup for cloud services, acquired and shut down by Facebook. Sourour writes
“Now instead of focusing on iterating on their product and growing their customer base, my client had to figure out how to either migrate to a self-hosted, open-source version of Parse, or replace Parse completely.”
But that’s actually a poor example because the problem with Parse wasn’t related to code dependency, but to an actual service gone. Imagine PayPal disappears tomorrow. It’s going to create huge headaches for a lot of businesses. The least of which would be related to code. In Sourour’s example there’s nothing wrong with the code. Actually Parse has been open sourced and several vendors, including Back4App and Amazon still support it. Is the service any good these days? I have no idea, but it’s likely that the code hasn’t changed much.
Sourour also gives AngularJS as an example for a library that’s changed a lot. This is a prime example of a huge change that’s left many companies befuddled on what to do next. And indeed companies face a tough decision on whether to stick to an aging framework, take a risk and migrate/rewrite the code in the newer version, or change frameworks altogether.
But to be fair, Google hasn’t abandoned AngularJS completely. Versions are still rolling out even to this very day, whilst Angular 6 is already out! Not only that, but Google has an upgrade path for existing projects.
Sourour also suggests taking into consideration several factors when evaluating a dependency, such as the number of its major releases, how long it’s been around, who’s behind it and how much it is used commercially. But that’s again where the claim falls flat, because of, again, AngularJS. This is a prime example of a great decision according to Sourour’s factors, but a problematic one in hindsight. And Google hasn’t made people’s lives any easier by rolling a competing framework that nobody uses.
Actually the one annoyance I keep bumping into has to do with more or less the entire NPM ecosystem. I don’t know about you but I’ve encountered at least a dozen times where a package didn’t install properly due to dependency version incompatibility. Can we do anything about that? Not much I guess. That’s the reality of open source development.
Risk management 100.9
So what are my tips for selecting a new code library to rely on:
- Who is using it and for how long? Are they satisfied with the result? Take VueJS as an example. There’s no corporation behind it, yet among others Alibaba felt it was reliable enough to use. That’s a very good indicator.
- Is it maintained on a regular basis and are issues handled well?
- Does it have a large user base in general?
- Ask yourself if the latest stable version is enough to supply all of your demands.
- Are there enough capable developers out there to work with chosen framework? Aurelia may get a lot of positive reviews, but how many actual developers are out there who know it?
So what can we take from all this? First we need to remember that an essential part of running a business (let alone starting it) is about risk management. There a million of different factors which can hurt a business and its legacy code as well as its dependencies is certainly one of them. As long as you approach your decision rationally you’re better off than choosing based on trends alone.
