Dependencies. 2024-05-31.

Dependencies.

Technicalities

When trying to solve a problem, I often begin by looking around, to see if it has already been solved by someone else. In software, this might be anything from a complete product, to a library, to a line or two of code. Provided that the goal is to solve the problem, rather than train one's problem-solving abilities, this approach can often make a lot of sense – why reinvent the wheel without good reason?

Now – each time you do this, you are depending on someone else to solve your problem. There are two critical questions which I think must be asked each time you do this:

1. Is this code really solving the your problem?
2. Does this code really work?

Someone else wrote this code. If they were working on the exact same problem as you, then great – you just need to make sure they got it right (though this is easier said than done).

At other times, though, they will have been solving a slightly different problem. Maybe theirs was more general, or less, or intended for different hardware, or different users, or a smaller userbase, or a much bigger userbase, or needed to be more robust, or didn't need to be robust at all, or needed to work for the next 50 years, or didn't need to work for more than an hour, or was designed to be updated every couple of days, or was built on top of ancient and vulnerable legacy software, or... And in all of these cases, of course, it could also be ridden with bugs!

There is much more to say about this on the technical side, but I'm not sure that I'm the best person to say it. Here are some experienced engineers discussing the same issue. I'll update this list if I find anything new.

1. Thorsten Ball - Using other people's code is not as good as I thought (2022).
2. A series of tweets by Mitchell Hashimoto, founder of HashiCorp - see the linked tweet and his replies.

Deferred costs: the illusion of ease

One reason it is so tempting to introduce a dependency, I think, is simply because it is easy. With open-source software, all you need is a git pull and an import; and without having to spend an ounce of effort or money, you have tens, hundreds, or even thousands of hours' worth of someone else's code working for you. It's as though you were doing some DIY work, and each time you got stuck, you could teleport whichever tools or materials you wanted right into your hand.

The problem is... where did that code come from? What was it for? How well has it been tested? To continue the DIY analogy, would you want to build your house out of bricks made by an amateur, or someone new to the trade? Or paving bricks you mistakenly materialised into your hand?

When there is a substantial cost to getting hold of something, whether time, money, energy, or anything else, it forces you to think about your decision before you act. You want it to be worth the price. The bigger the cost, the more you'd want to think about it.

Importing other people's code takes no thought whatsoever. In the short-term, it's often the easiest thing you can do – far easier than solving a problem yourself. But if their code is not truly what you need, you may be paying for it at some indeterminate point in the future. And the more you've built on top of shaky foundations, the more work you're going to have to do to fix it.

So perhaps we can consider certain unfamiliar dependencies as having a potential deferred cost; a possibility we should consider before relying on them too heavily. More simply put, there's no such thing as a free lunch; or, he who does not work, neither shall he eat.