This is still the header! Main site

Dependencies: the Evil of Redoing Stuff, part 1


... in software!

This is post no. 82 for Kev Quirk's #100DaysToOffload challenge. The point is to write many things, not to write good ones. Please adjust quality expectations accordingly :)

... so what are dependencies anyway?

In an ideal world, you would start with knowing what you'd like to write a computer program for. Then, you'd write it. And then it would run. That's it. Fairly simple.

Specification > Source code > Compiled binary

Sadly, the world is more complicated than this. You might have had the wrong idea about the program might need to do (thus, the specs might have changed); you might also want to port the entire thing to a different kind of computer. You generally don't want to start over entirely when this happens.

Worse yet, you might not be the only person working on this. Let's say, you're using a library to e.g. decode images in your program. If the author of that program changes something... well, you generally don't want to start over either.

You can actually imagine code that is essentially impossible to change after the fact; e.g. if you hand-optimize each byte of it to mean something else at some other point during execution. You generally do not want this though. It not happening is pretty much the entire point of nice software design.

But... what is a "dependency" really? If you generalize things a bit, things might end up looking different:

problem description > solution in your head > source code > compiled binary

Technically, if a tiny part of the problem description changes, in the worst case, you'd need to do all the work on all the downstream artifacts: rethink your solution, rewrite the code, and re-run the compiler. In practice though, these decompose fairly neatly into multiple, independent pieces:

The reason you don't have to start over is that some of these parts decompose into different parts.

we factored apart a color of a button into a different part of the tree

As long as the "button color" parts don't affect the rest of the code, if your spec changes ("can we make that button less prominent?"), you only have to think a bit more, write a line of code and recompile, but all your algorithms are still OK.

... with all this formalism set up... well, in our next episode, we'll talk about source and binary compatibility, along with interfaces. Meanwhile, the main takeaway of today's post is probably that it is possible to put emojis into graphviz graphs!

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.