by Abe Wheeler
Every dependency is a security threat, a maintenance burden, and a future migration. We may save ourselves from writing a for
loop right now,
but when that brave Nebraskan finally throws in the towel, we're in trouble.
But we don't want to reinvent the wheel (we're developers, not wheelers). Some dependencies are too good to pass up for our projects. After all, why would giants have shoulders if we weren't meant to stand on them?
Like everything else in software engineering, dependencies are just tradeoffs all the way down. In that spirit, I've created a ledger for valuing a dependency, along with some questions to help evaluate each entry:
Assets | Liabilities |
---|---|
Ongoing time savings:
How much time do I save every day by using this?
|
License:
Am I allowed to use this?
How likely is it that this license will change? |
Immediate time savings:
How long would it take to build what I need myself?
|
Security risk:
Do I trust the people that made this?
Do I trust their judgement? Their dependencies? Their future maintainers? |
Community:
Are my teammates already familiar with this?
Will this help me recruit teammates? How much support can I get? Am I likely to get new helpful features? |
Maintenance burden:
How stable is it?
How often do I have to handle updates? Are those often backwards-incompatible? Will I likely have to contribute to this? How easy would that be? |
Abandonment risk:
How many people use this?
When was it last updated? Is there an institution behind this? Is it maintained by the node community? (abandonment is imminent) |
|
Bloat:
How much of this dependency do I not need?
What will that do to my project complexity, build times, latency, and network usage? |
What did I miss?