Dec 04 2019
Carefully Download It
Are dependencies good or bad? This is a hot topic that seems to make its way into Hacker News quite often.
There is a camp of people who insist that self-reliance and minimal dependencies is clearly the right way. Doing It Yourself (DIY) ensures that the code executed is within the project workspace bounds. With the constraints of the workspace, it is much easier to trace through and debug. The primary downside is that it takes a looooooong time to reimplement the features that could be simply downloaded.
On the other side of the coin, the Just Download It (JDI) group doesn’t have time to reimplement something that is already out there. This gives a much quicker time to market, so stakeholders would much prefer this option. Utilizing dependencies also defers design decisions to people who are more likely to specialize in the respective feature-space. However, beware of the hellish dependency upgrade process. This will undoubtedly occur when a large set of dependencies have accumulated.
As with most things, finding a balance between the two is likely the best course of action. However, the major key is having the mindset behind when to DIY vs JDI.
What’s the harm in another dependency?
As a novice, I was very much a Just Download It kind of person. Yes, I got to market fairly quick – especially because I had less of an idea on how to express solutions in code. As time went on, the JDI philosophy began to bite me. Some of the issues that I encountered were:
- Dependency upgrade hell. It’s easier to upgrade a couple core dependencies than a swath of them.
- Too much time lost reading through the dependency docs.
- The “complecting” issue as noted by Rich Hickey (https://www.youtube.com/watch?v=rI8tNMsozo0). This one is not very obvious, but a killer in the realm of technical debt.
The pendulum swings to the other side
The only proper response to these things was to swing to the other side of the spectrum. Welcome to the Do It Yourself mentality. When writing everything yourself, only you become 100% accountable for the software and all of the defects it may contain. With everything in the same workspace, file traversal is easy as pie. This makes maintainability easier since all of the code is easy to access. I can also define the interfaces exactly how I want!
Wait, what Mr. Manager? You need this by the end of the day? Hmm… I could download this dependency and just get on with my life. (yes… I know, it’s not always good to cave to all of the manager’s time-lines. This would have to be a separate post).
Taking real responsibility for your code
As it turns out, sometimes it is good to JDI. However, instead of “Just” Downloading It, I would argue that you “Carefully” Download It (CDI). Consider adopting the mindset where a dependency becomes one with your codebase. This way, all interfaces, defects, and features become 100% your own responsibility. In turn, this encourages you to do your homework on the best possible dependency that you can introduce into your project. Who knows, maybe this would even push you into the open source project and lead to code contributions. Even if you do not contribute, hopefully this philosophy will give you a greater appreciation for those who donate much of their time to open source. Above all, CDI acknowledges that dependency updates are a bonus, and not taken for granted.
I hope I made a somewhat convincing argument to take the middle road and Carefully Download It. CDI introduces a whole new level of software responsibility that is a lot more involved than JDI or DIY. Adopting this shift might just help you get to the next level.