What is enduring software?
"Well, that sort of has always meant, is, uh, it's hard for something to grow on something that's moving." McMurphey // One Flew Over the Cuckoo's Nest (1975).
By "enduring software," I mean a computer program that you can compile and run successfully after years passed from the last time you did it. It might seem not a big deal, but it really is. A typical sophisticated software package is usually backed by many libraries coming from different sources. You pick "this" and "this" and build up your Frankenstein without developing routine stuff from scratch. For example, Analysis Situs is based on at least five 3-rd party libraries: OpenCascade, VTK, Qt, Tcl, Active Data, not to mention some optional dependencies, such as TBB, for example. This is not a significant number of extra deps, in fact. That's a pretty moderate number. Looking at any CAD system's installation folder, you will find an absolutely mind-blowing quantity of dynamic libs wisely architectured into pretty sophisticated software. So what's the problem?
The problem is maintainability. Let's skip scenarios when the package you rely upon dies, goes out of support, or changes its license to some prohibitive terms. All this may happen, but these are definitely some bifurcation points in the software's life cycle. The real problem is that the libraries you're using are living products whose developers have their own vision on how to evolve their stuff, and you have just zero control over these things. In the cases you've got paid maintenance, you may expect some handy tips on migration, but migration itself is rarely a cheap business. Last time I tried to port Analysis Situs to VTK 9.0 (from its previous version 8.2) anticipating small benefits from the updated visualization engine, I spent a couple of days to fight unobvious regressions. And finally, I gave it up as there were too many. The worst thing is that sometimes you update just to stay on track. Quite often, you do not even benefit from bug fixes or new features, you just want your product to be on the "cutting edge."
The more I am into this, the more I think that choosing "right" dependencies is a critical architectural decision you have to take as early as possible. Some dependencies, like Eigen, are as persistent as mountain rocks. Even if you notice them upgraded, you're unlikely to get into trouble as the math they are supposed to do is basically right or wrong. There is no huge scale of "gray" like in visualization (VTK) or GUI (Qt) packages, only black and white.
If you happened to base your software on volatile "frontend" libs ("backend" libs are no better, but their updates are often easier to survive), you're going to have migration troubles, sooner or later. And you know what? It is too expensive for an indie developer to migrate, migrate, and migrate again. That whole migration BS is for the rich guys, i.e., the companies who can waste their poor employees' lifetime to just anything. They simply don't care.
 |
Klein bottle's isolines. No VTK, dude. Pure OpenGL only. |
Indie developer? Write your software from scratch. Or, at least, ground it on the libs that are proven to be persistent. Some examples from my daily practice are SQLite and Eigen. Forget all shitty deps. Be cool and hackish. Eat meat.
Bonus: photo from this night (I used the smartphone's camera):
 |
Comet C/2020 F3 (NEOWISE). |
Want to discuss this? Jump in to our forum.