Never use a dependency that you could replace with an afternoon of programming
blog.carlmjohnson.net
Never use a dependency that you could replace with an afternoon of programming
1–10 of 333 posts
Re: Never use a dependency that you could replace with an afternoon of programming
#2why not just copy the code from the dependency into your own sources?
Re: Never use a dependency that you could replace with an afternoon of programming
#3I'm not sure if I agree - commonly-used packages will have known and documented faults, while validating something you (your organization) created can be challenging.
Dance with the devil you know and all that.
Re: Never use a dependency that you could replace with an afternoon of programming
#4I recall using an unusual library a while ago where the author had embedded their own log4j-style implementation. I couldn't configure that the same way I configured other logging.
Hardly a problem today since I just write to `stderr` and have the container log aggregator push elsewhere but boy was it annoying.
Re: Never use a dependency that you could replace with an afternoon of programming
#5Avoiding dependencies is a noble goal, and something to be valued, but this simple rule is too simplistic.
The problem lies in the fact that there are a great many things I can hack together in an afternoon to "replace" some kind of external dependency, but the quality discrepancy of these hacks is highly variant. My understanding of what can or should be done in an afternoon might differ with my colleagues'.
Unfortunately, like all things in engineering, you have to carefully reason about the pros/cons, requirements, and costs. After that analysis, you can make a judgment on depend vs. build (also, buy vs. build).
Re: Never use a dependency that you could replace with an afternoon of programming
#6This is horrible advice. There's a reason that you don't write your own hashtable implementations.
Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version.
All that work of finding existing solutions and learning how to use them? That's part of the job.
Find a bug in the dependency? Submit a patch.
Worried about the dependency changing? Lock the version.
Too many external repos to retrieve those dependencies? Use a local cache.
Don't reinvent the wheel.
Re: Never use a dependency that you could replace with an afternoon of programming
#7Agree-ish - buttt makes me think: How about... dont keep a dependency you could replace with an afternoon of programming?
Factor, re-factor, and (most especially) DELETE should be tools in the toolbox -- but see if you need it/keep it (e.g. protoype it in, etc first) before you re-write.
Re: Never use a dependency that you could replace with an afternoon of programming
#8A hundred afternoons later my small application is finally completed; now I must maintain update and document it all for ever rather than relying on third party components.
What I really wish is people would look closer to home; for example use some of the thousands of functions that ship with your operating system before downloading a package.
Re: Never use a dependency that you could replace with an afternoon of programming
#9why not just copy the code from the dependency into your own sources?
Indeed, one could even automate the process, some sort of tool that automatically copies the dependency’s code, kinda like an install. I think someone already wrote such tool.
Re: Never use a dependency that you could replace with an afternoon of programming
#10This reminds me of the Node left-pad module problem in a way. I think if something is so trivial to write, you should write it rather than using a dependency.
If it is non-trivial, I prefer the official standard libraries for a programming language. That is if a solution exists in the standard library.
I think the Go standard library with its batteries included mantra and the level of support it gets is good example of a library that should be used when a solution exists within it or by utilizing it.