| |
Somewhere in the universe, there's the alien equivalent of a graduate student who is deeply troubled. They decided to study the code we humans were producing as a way of understanding our societal values. | | |
|
What they found terrifies them. Clearly, humans are risk-seeking creatures who value complexity. What's worse, humans are obviously ridiculously bound to each other; based on the way humans use dependencies in their code, they are clearly eager to put their trust and futures in the hands of total strangers. | | |
|
The student has no choice. They report Earth to the Department of Planetary Sanitation for immediate cleanup, and then go looking for a new research topic. | | |
|
| |
Players of the classic game Katamari Damacy attempt to rebuild the universe by rolling around a ball. Things that are smaller than the ball will stick to it, making the ball bigger, and hence capable of picking up more stuff. | | |
|
Clearly, people who played the game in their youth have become software developers, and they have decided that their mission is to fill the universe with code. They do so not with a sticky ball, but by using dependencies. | | |
|
Add one dependency to a project, and it grows a little. But there's a twist, because each dependency may itself include its own dependencies, which also add to your project. | | |
|
What's more, there are amazing power ups. Some dependencies bring along thousands of subdependencies. With almost no effort on your part, you can turn your humble, small project into a world-crushing monster of code. You can recognize these power-ups easily: they're often called frameworks. | | |
|
| |
Other developers play mini games with different objectives. Sometimes their aim is to add the newest of everything to a project. Other times they decide to go deep, adding dependencies all related to a particular area (perhaps security or data access). They may not know exactly what each dependency does, but add enough of them and surely one will do some good. | | |
|
 |
| |
| |
You might be thinking that dependencies are good. After all, why write code when someone else has already done it? | | |
|
If the dependency you are using is small and well targeted, then perhaps you can consider it (although if it's that small, you could probably get an AI to knock out a local version while you fetch a cup of coffee). | | |
|
Otherwise, dependencies are a drain on your project. Short term, they can move you forwards. Longer term, though, you're stuck trying to adapt interfaces where the dependency does't quite meet your needs. You'll spend days trying to update your software and discover that dependencies that used to work together now require incompatible sub dependencies. | | |
|
Dependencies are a security risk, too. When was the last time you audited the source code of each of the dependencies you joyfully downloaded from some repository? | | |
|
| |
You obviously can't write code today without dependencies. | | |
|
But when you do add one to your project, always remember that that single line in some manifest file actually represents a large number of future unknowns; each dependency is a debt that might need to be repaid. | | |
|
And if you code using AI, be extra careful. In my experience AIs just love adding dependencies to a project. They never stop to think of long-term consequences—if a dependency helps them reach the next goal, then it's included. | | |
|
| |
Most package managers maintain a local lock file where they record the version numbers of both direct and indirect dependencies. Look into your last couple of projects and see how many dependencies each had in total. 100? 1,000? 5,000? | | |
|
Whatever the number, it tells you how many external developments (which are outside your control) directly impact your work. | | |
|
