Hindsight 2021

April 26th, 2021

September 2016, from the co-founder of Lyft (emphasis on the timeline mine):

Last January, Lyft announced a partnership with General Motors to launch an on-demand network of autonomous vehicles. If you live in San Francisco or Phoenix, you may have seen these cars on the road, and within five years a fully autonomous fleet of cars will provide the majority of Lyft rides across the country.

December 2020, Uber exiting the much-hyped business of replacing human drivers with self-driving cars:

Uber Technologies Inc. sold its self-driving-car unit to a Silicon Valley competitor, Aurora Innovation Inc., in the latest business exit by the ride-hailing company as it aims to deliver on a promise to shareholders to become profitable.

April 2021, right around the projected mark of 2021 being the year where “a fully autonomous fleets of cars will provide the majority of Lyft rides across the country”, Lyft offloading their (failed) self-driving car division to Toyota:

Lyft, Inc. (LYFT) announced today that the company has signed an agreement with Woven Planet Holdings, Inc., (“Woven Planet”), a subsidiary of Toyota Motor Corporation, for the acquisition of Lyft’s self-driving vehicle division, Level 5

As I said just two years ago, self-driving cars are highly unlikely to happen within the next 20 years, with the following disclaimer:

By self-driving cars I mean the combination of technology and legislature that would give me the option, owned, leased or on-demand, to have a vehicle for myself and my family to get me from point A to point B at my time of choosing. The only mandatory condition is that it would not require me to pay any attention to what is happening during the trip.

If I am required – by technology or by law – to be able to take over the control of the vehicle at any point in time, that is not a self-driving car in my world. If the technology is only available on specific roads (highways, for example) or under very specific weather conditions, that is also not a self-driving car in my world.

I still stand by my prediction. If anything, I’ll make you another deal. As long as the loudest voices in the business of selling this pipe dream keep on saying that self-driving cars will be here within 5 years, I’ll keep on saying that self-driving cars will not happen in at least 20 years. Let’s see who wins this little game.

Who are you, exactly?

April 22nd, 2021

Had a phone call from the bank earlier today. Nothing special. Someone from customer relations department, wanting to make sure that I’m getting what I want from the bank (like, don’t lose my money, otherwise we’re good, I guess?). But something was weird.

It was maybe a five minute call, with him doing most of the talking, and me doing most of the listening. But to be honest, all throughout the call I was not quite 100% sure that I was speaking with a real person. He was sticking to the script, which is understandable since he probably has another few dozen similar calls to make today. And then he was taking a pause to wait for my answer. It really felt like I was talking to some sort of an IVR [interactive voice response] system, where based on my answers they would choose their next section.

So he was sticking to his script (assuming that it was a real person). And I kept on thinking that I should stick to simple answers to keep that system (in case it was an automated system) on track as well.

It’s weird. There’s so much automation in these interactions (are chat bots still a thing?) that even a few hours later I still don’t know if he was a human, or a machine.


April 13th, 2021

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).