You wouldn’t think that a 16th century poet from England would know much about software. Surprisingly, however, it turns out that John Donne’s Devotions upon Emergent Occasions may as well be about software engineering.

No man is an island entire of itself; every man
is a piece of the continent, a part of the main;
if a clod be washed away by the sea, Europe
is the less […]

Like mankind, practically all software is interconnected. It is no exaggeration to say that every piece of software worth its salt relies on someone else’s software to function. If you can name a chipset firmware, operating system, desktop application, web application, mobile app, API endpoint, IoT device, or data science library, it’s almost certain that software “owes” something to other open or closed source software.

For example, even if you don’t know how to program in languages like Python or Java, you can open a source file and see how frequently the word “import” shows up at the beginning of a file. Each of these “import” statements is an instruction for one “piece” of software to “share something” with another piece of software. Sometimes, this sharing occurs “inside” of an application or library, but often, this sharing “crosses the boundaries” from one application or library to another.

When one application or library “crosses the boundary” to import something else, we have a software dependency. These dependencies are arguably what make software so powerful – because each developer can stand on the shoulders of those who came before them (assuming it’s permissible!), the effort to create new software generally decreases over time.

You might be asking: are dependencies always good when you build software? (Spoiler alert: they’re not.) The answer, like in building a house or baking a cake, is that your final product can only be as good as the materials you use. In software, dependencies are like the plywood or flour that you use to build or bake. Even if you’re the world’s best baker, your cakes will suffer if your flour is moldy or milled wrong.

Luckily, there are processes and technologies that developers can leverage to ensure that the dependencies they choose meet their needs – and stay that way over time. We’ll be covering this and more in posts to come. Stay tuned!