Recently there has been a lot of discussion around project dependencies. As a result, it has been pretty hard to decide when and if to include a new gem into a project.
Overall, I think I tend to weigh in heavier on the side of exclude everything possible except what is absolutely necessary. That being said, here’s the mental check list I tend to work through when deciding whether or not to include a dependency.
Is it something that I really need? Is it something that I can write myself?
Rails or MySQL might be something I’d rather not write because it might take a while versus an authorization component that would take only a few hours or days. It might be just as quick to write an authorization component then attempt to understand and debug another developers intentions.
Am I ready to support the Gem if the maintainers won’t?
Is this something I want to continue to maintain and grok a year from now, or will the Gem be obsolete?
Will it help me achieve a deliverables drop dead date?
Will it help me ensure that a deadline will not slip?
Can I accelerate toward a deliverable by including a Gem and then revisit the dependency?
What happens when I need to modify the Gem to tailor it to my needs? How do I keep up with the fixes from the original branch?
I tend to error on the side of Gems lasting for 6-18 months, then they’re essentially dead or re-written by the same author.
Is DRYing up my code really that important?
I’ve found that it is easy for people to ramp up on verbose code, especially verbose test code versus ramping up on code that includes a hierarchy of dependencies that one would need to sort through.
Continuing this thought, is there a ramp up time? And how many people will need to ramp up on the dependent Gem?
Further more, do I need total control over the component that I’m thinking about including?
Am I worried about a rogue check in that might impact the end-user experience when I rebase?
Is there a performance implication that I would like better to manage?
In summary, I guess I tend to get a bit uncomfortable with a large number of dependencies and wind up continually try to reduce the number of project dependencies.
About the Author