# On Dependency Hell

One of the things I often complain about is the software industry's absolute
obsession with code reuse at all costs.  But, as time goes on, we're
starting to feel the symptoms of this obsession, such as supply chain
security issues and transitive dependency issues.

Until something significant happens, the latter issue seems to get all the
press.  It's a rare day that goes by when someone doesn't write an article,
publish a toot, or post a tweet either online or in an offline journal that
talk about how programming today requires so many dependencies, and
how any given application will only use about (just hand-waving here) 5% of
them.  Pick a figure; it doesn't matter.  I almost guarantee you've seen at
least one article along these lines in the last month, and even if the exact
figure is different, guaranteed that number will be substantially less than
50%.

You can't have your cake and eat it too.  There's just no way to
support code reuse as an orthodoxy and still have the benefit of reduced
dependency loads.  You just can't.

Sufficiently smart compilers, like Rust or Go, have techniques for
mitigating how much code it can safely elide from a finished build.  But
that still doesn't solve the problem of having to audit dependencies to
begin with.  Sure, you might only need 5% of those dependencies, and the
compiler might actually use only those 5% in the finished build, but
are you willing to stake your career reviewing the remaining 95% of the code
for potential security issues that might get included through an
unforeseen transitive dependency?  Unless you work in the security field as
a specialist, no; literally ain't nobody got time for that.

I don't have solutions for these problems.

One of the things that I do have, however, which is something I have in
common with Chuck Moore, is a strong preference for writing my own
subroutines and libraries.  From Programming in a Problem-Oriented
Language, Chuck writes:


The Basic Principle has another corollary:

- Do It Yourself!

Now we get down the the nitty-gritty. This is our first clash with the
establishment. The conventionsl(sic) approach, enforced to a greater or
lesser extent, is that you shall use a standard subroutine. I say that you
should write your own subroutines.

...

But suppose everyone wrote their own subroutines? Isn't that a step
backward; away from the millenium when our programs are machine independent,
when we all write in the same language, maybe even on the same computer? Let
me take a stand: I can't solve the problems of the world. With luck, I can
write a good program.


This doesn't mean I want to re-invent the wheel all the time.  I really
prefer writing my code with a published standard implementation to guide me.
E.g., a peer-reviewed computer science journal article that fully document
how to implement a B-tree, for example (none of this "node deletion is left
as an exercise to the reader" bullshit).  Over time, I would like to build
up my own sort of "tool box" with code I've written, and take with me place
to place.  But, I also know this won't scale in any reasonable commercial
endeavor.

I mean, this is exactly how today's commercial software industry first grew
up (we didn't have the benefit of the Internet or large code repositories in
the 60s and 70s, so knowledge had to spread somehow), and yet
economic pressures caused software development to evolve into the mess we
have today, so...

Just one more thing Chuck Moore was right about all along, I guess.  But,
there's no going back.  So, there's no point in complaining about it
anymore, either.