A few years ago I was visiting the Computer History Museum in Mountain View, and it was fascinating to see physical manifestations of technology almost disappearing before my eyes. Starting with huge chunks of metal, glass and plastic, pieces that probably needed a few people just to move around the room. Getting smaller and smaller into the 70s, the 80s, the 90s. A piece of silicon, an integrated circuit of some kind, right under the magnifying glass so that you could see the finer details. As if a human eye can comprehend anything at that scale.
As the layout of the self-guided tour took me closer to the present time, it traced another, perhaps untold aspect, of Moore’s law – consumerization of computing technology. Machines that were not only getting smaller and faster, but also cheaper. Cheap enough to become more affordable for personal usage at home. Maybe to do a spreadsheet or two to keep track of your expenses. And certainly to play a video game or two.
I’ve had a Mikrosha. It was amazing to be a high schooler and have a computer that you could call your own. I remember finding this place that sold software for it, maybe half an hour away from where we lived. They had a xeroxed printout of their “catalog”. Every piece of software for that computer came on cassette tapes. Mikrosha itself was an integrated plastic box with the mainboard, the keyboard and a mono speaker. You’d connect it to a TV. And you’d connect it to a tape recorder to load programs. And hope that your tape recorder wouldn’t chew up even one inch of that precious cassette tape. Because if that happened, that copy of the game was lost forever and you’d have to buy a whole new tape to replace it.
There are plenty of emulators and simulators of all kinds to let you play (legally or maybe not so legally) older video games from a few decades ago. But the thing is, it’s not exactly the same experience. There is no tension of waiting five minutes to have the binary code loaded before the game can start. There is no exhilaration that you feel at the end of it that the tape lived to survive yet another load. You might see the 16-bit, 8-bit or even black-and-white graphics, but it’s not the same. The grainy feel of the huge pixels, the color fringes of a cathode ray tube, the slight hum of the TV box itself – all have been sterilized away.
The games I’m playing today are orders of magnitude more sophisticated. For a number of reasons, technical as well as business, some of the game code is never found on my device. Maybe it’s the piece that aims to prevent piracy. Maybe it’s the piece that does the multiplayer thing. Maybe it’s the piece that the developers wanted to be on their servers so that they could update it at any time without having to issue a client-side update.
I have little to no hope of being able to play any of these games in a couple of decades. There’s going to be only so much that even the most dedicated fan base would be able to recreate, even before an armada of lawyers starts sending threatening letters. Our devices are lighter. Smaller. More powerful. But also more fragile.
Every few months I lose another piece of a “thing” that is not supported any more. Maybe it didn’t make enough profit, or no profit at all. Maybe the company decided to pivot into a more profitable niche. Maybe that single developer doesn’t have time or passion to support that library. You could say that I can stay on that old version, but even that is slipping away. That old version has dependencies. And as the world moves on, those dependencies start breaking.
I’ve been writing my desktop libraries for a bit now. Started back in 2005, which makes it 16 years and running now. I hope to have it going for another 15-20 years. Such a time horizon gives you an interesting perspective.
The most obvious and popular choice for any “thing” that a software project needs may be there for a while. Until it is not. It may happen almost overnight, like the shutdown of java.net. It may happen with a few months’ warning, like the shutdown of JCenter. It may be that the thing that you were using was not the best thing ever, and now all the cool kids are using some new thing. Maybe it’s the choice of the version control system. Maybe it’s the choice of the build tool. Maybe it’s the choice of the dependency management system. Maybe it’s the choice of where you host your “artifacts”. Maybe it’s the choice of the programming language, or the platform you’re building on top of.
Is Gradle going away any time soon? Is Git? Is Github? Can I be confident that I’ll be hosting my artifacts on Maven Central in the next five years? In the next ten? In the next twenty?
Having been around for a while gives you a different perspective. The more you become “invested” in a thing, the more painful it becomes to move to a different thing. Maybe the old thing is just old, and the new thing is measurably better. Or maybe the old thing is just not there one day, and you don’t have any choice to move to a new thing. Not because you wanted to. The old thing was perfectly fine for what you needed. But it’s just not there. Gone.
I try to depend as little as possible on these things. I don’t want to become invested in them to the point where the very existence of my thing depends on that other thing. I keep my build scripts as simple as possible. I don’t integrate with any of the Github’s hooks, flows or whatever they happen to call them these days. I even upload a copy of the binary artifacts for every release to the repository.
I don’t know which one of the things that I’m using today will simply not be there in 10-15 years. I know for certain that the probability of all of them being there is quite low.
Just yesterday I spent about two hours moving from this one thing to another thing. Both of them automate uploading snapshots and release binaries. That older thing is still around, but it’s not supporting the latest major release of yet another thing. So I either stay on older versions of both things, or move on to some thing that is still being actively supported. Until it, inevitably, is not supported any more. As a popular commercial goes, I know a thing or two, because I’ve seen a thing or two. At this point, it is as close to a certainty as it can get.
I may not know which thing will break next. All I can do is to try and minimize how much I depend on every one of those things, so that I can spend as little time as possible on all the things around the actual thing I want to spend my time on. Until I myself, inevitably, move on and my thing breaks as well.
