The Joy Of Dependencies

Whether on our favorite UNIX flavor, or on our projects, we are pretty much all dreading the time when we have to update the dependencies. What will be broken? How long will it take? How many platforms/users will we have to leave hanging?

We obviously depend on a number of libraries and pieces of code written in another time, for another project, and/or by somebody else. Whether it’s something big (like the OS itself — just read the forums for cries of despair), or small (OK, so, apparently, that lib takes UTF-8 strings instead of UTF-16 ones, now…), no dependency update is hassle-free and painless. None. Never.

Once upon a time, a long long time ago, in a city not that far away, I had to write tools for a small printing business. My major dependencies were the print driver (which drove a huge triple-rotor, 12 ink barrels, monstrosity), Quark XPress, QuickTime and MacOS (Classic, but I can’t recall the exact version number).

Once it was up and running, after a lot of sweating and swearing, they didn’t dare upgrade anything. If a customer came with a newer version of their XPress document, they just told them to export it again in a more compatible format. And that was it.

Nowadays, with users being informed constantly about updates (and not trained for it), it’s up to us developers to make sure we have the backward compatibility (what if a user upgrades our app, but not the system?), and the forward one (try to keep up with the general thrust of evolution and prepare the code for “easy” updates), and of course fixing the existing bugs.

This obviously adds a lot of overhead to our work, which is very hard to convey. “It’s the fault of that OS maker”, or “yeah but they broke it in that version of the lib”, is something a fellow developer might accept as an excuse, but a paying customer?

And we can’t blame them! How about if someone told you your car could only go on this freeway or in this town, but nowhere else, until they have upgraded the road? Especially if you don’t actually see the difference…

So we’re stuck between dependencies which evolve according to their own constraints and objectives, and users who legitimately want the thing they paid for to work. Not mentioning the apparently dreadful one-star-review (for me, it’s mostly people who don’t read the instructions, then complain about things that are stated somewhere, but hey…), it’s a reputation do-or-die. And our code is literally filling up with workarounds for this or that version of the OS, the libs we depend on.

Why do I go on about this anyway? Well three things: Yoann (@ygini on twitter) and I both had to upgrade our ports on a BSD, which is long and/or painful, because each lib depends on at least 3 others, and I tried to fix a few bugs in an old project of mine I will definitely release someday. Both of them took wayyyyyyyyyyy longer than any “regular user” would accept. We are talking weeks or days of down or crippled-service time here.

I am still looking for a way to make sure people depending on me make the difference between a lame excuse (“they changed something so it doesn’t work anymore”) and a good excuse (“they changed something so it doesn’t work anymore”), and will take any good advice on the topic.


Leave a Reply