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.

Two quotes that I keep on coming back to. The first is a tweet from Nicoll Hunt from 2014:

The first step of any project is to grossly underestimate its complexity and difficulty

The second is from a German field marshal by the name of Helmuth von Moltke (formulated in the 19th century):

No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength

Which, in its more modern reconfiguration, is frequently referred to as “No plan survives contact with the enemy”.

Applied to design documents in the field of software engineering, one might say that “no design document survives contact with the codebase”. This has largely been true for myself, at least. Which doesn’t leave a lot of options.

The first one is to not write any design documents at all, and kind of discover-as-you-go. The code itself becomes the design document, hopefully by either being clear enough or by being well documented.

The second option is to write a document, and then keep on updating it as you’re discovering all the things that can only be discovered during the implementation.

The third option is to write a document, pretend that it accounts for every possible scenario, make an elaborate planning chart on how much time exactly the implementation phase will take, and then pretend to be surprised when the real numbers had little to do with that chart.

The fourth option is where the final implementation has nothing to do with the design document, and nobody bothered to spend any time updating that doc.

And the fifth option is to write a design document, do the implementation, and then write another design document that describes the actual implementation and compares the original approach with what actually worked. A post-mortem, if you will, on the original design document. What worked (probably nothing). What did not (probably everything). What can we learn for the next time (probably nothing, again).

In the last four years, this country has lived at the whim of an immoral, narcissistic, incompetent and corrupt con-man. An abject failure as a businessman, only surviving by the grace of the long-broken edges of our judicial system. A sinister ghost during his campaign that rode the winds of divisiveness and demonization of the “other” side. An unprepared, uninterested in and thoroughly unqualified for the job, he brought shame and utter disgrace to the highest public office in the land.

I am despondent about the unchecked descent into madness that we’ve witnessed during his term. I am proud that my home state of Georgia took a look at two politicians that decided to closely align themselves with his vitriolic rhetoric, and gently showed them the door.

His biggest transgression by far has been to aim to thoroughly destroy the most basic foundations of this democracy. To shatter people’s faith and trust in the fairness and integrity of our elections. I can only hope that every single excuse of a public servant that has supported that rhetoric will find themselves voted out of our institutions.

Checking in on an earlier post from last year on being skeptical on the whole self-driving cars thing, I got reminded of this article from last April and the quote from Elon Musk:

As for full autonomy, Musk noted: “the software problem should not be minimized.” He continued that, “it’s a very difficult software problem.” Still, he promised that Teslas will be capable of self-driving by the end of this year and self-driving robo-taxis will be on the road in 2020. Also, in two years, the company will be making cars without steering wheels or pedals at all.

“If you fast forward a year, maybe a year three months, we’ll have over a million robo-taxis on the road.”

Usually futurists give themselves a bit more breathing room, say 25-30 years. By which time they are either no longer with us, or can claim to have been let down by the inept technologists who have failed to deliver on their “vision”. In this particular case though, Tesla is barely struggling to get to level 2 which is basic, partial automation. We’re quite a long way off from a million robo-taxis on the road.

In the meanwhile, Tesla’s official page on autopilot is using some clever wording that makes it seem that they are already at full self driving level 5 (highlights mine):

All new Tesla cars have the hardware needed in the future for full self-driving in almost all circumstances. The system is designed to be able to conduct short and long distance trips with no action required by the person in the driver’s seat.

All you will need to do is get in and tell your car where to go. If you don’t say anything, the car will look at your calendar and take you there as the assumed destination or just home if nothing is on the calendar. Your Tesla will figure out the optimal route, navigate urban streets (even without lane markings), manage complex intersections with traffic lights, stop signs and roundabouts, and handle densely packed freeways with cars moving at high speed. When you arrive at your destination, simply step out at the entrance and your car will enter park seek mode, automatically search for a spot and park itself. A tap on your phone summons it back to you.

Sprinkle a few “will”s in there, and you make it sound like it’s yours once you buy one of their cars. While the press kit is a bit more realistic, bringing it down quite a few notches (highlights mine):

Autopilot is an advanced driver assistance system that is classified as a Level 2 automated system according to SAE J3016, which is endorsed by the National Highway Traffic Safety Administration. This means Autopilot also helps with driver supervision. One of our main motivations for Autopilot is to help increase road safety, and it’s this philosophy that drives our development, validation, and rollout decisions.

Autopilot is intended for use only with a fully attentive driver who has their hands on the wheel and is prepared to take over at any time. While Autopilot is designed to become more capable over time, in its current form, it is not a self-driving system, it does not turn a Tesla into an autonomous vehicle, and it does not allow the driver to abdicate responsibility.

So maybe, at some point in the future, it “will” be there. But not any day now, despite the ongoing barrage of lofty promises.