On reliability and simplicity

Published 2025-04-18

tag(s): #link-post #random-thoughts

A while ago I read this great article in The Jolly Teapot, and I am trying to do better at sharing the things that I read, then think "I should share this" (or comment on it)...and then leave lingering forever either in a tab to the far left of the browser, or a rarely-revisited bookmark.
Anyway, the article is: The nice feeling of trusting tools

Some quotes with light commentary:

This little anecdote makes me smile thinking about it, and I think it is a testament to both how we kind of expect the worst in technology — I know I do — and to how we take reliable tools for granted, to the point of not noticing how great they actually are.

I know this is certainly the case for me, as Nicolas explains in his post, there are complexity reasons why technology sometimes is less reliable than every day objects. And I would add that I think it is time we people working in technology (in my case software, but hardware too) take a hard look around daily stuff for inspiration.
This is a bit related to the previous post on friction, because I think a lot of the pain is self inflicted when we try to minimize friction to the point that every single action in most software feels Rube Goldberg-esque.

For example, something at work is moving from mass-transfer of data to an API endpoint. This change is being bestowed upon us by a third party.
Are APIs the more modern approach? Sure. Does this data change often enough that we need some sort of real time update? No. Will anyone benefit from the "modern" approach of having a subscriber/publisher, events, etc? Well, not really. None of the things we will build to support this will be rocket science, but they do increase complexity, more moving parts.
A younger, or more optimistic, developer would argue that these are well trodden patterns and this can be built to be very reliable. And it is true. But more moving parts always implies more things that can break down, that need maintenance...the good old querying and flat file transfer we have today, while arcane, serves our needs so well.

I have the same feeling towards everything labelled “smart home.” Sure, controlling the lights and the blinds with an app is cool and automating their actions is useful, but I think I’ll stick to the good old reliable light switches and cords for now. They sure can break too, they sure can fail, but if they do, the source of the issue will be easily identified, and long minutes won’t be needed to figure out if this is the app failing, or the Wi-Fi, or the battery of the hub device, or the light or blind itself.

I think this passage is similar to my observations about adding moving parts that are not really needed. With the smart home example - yes it is cool to dim your light from your phone[1]. But, will it kill you to stand up and flick the switch? Isn't it actually better? That little (again) friction?

I jokingly mentioned Emacs in a footnote - all these points relate to my choice to use the same editor for everything. And to the reduction of my configuration to the fewest amount of external dependencies, in favor of "as little as it is enough".

Footnotes
  1. Or use an API that you call from Emacs =P Which is funny to bring up in the context of simplicity.

Share your thoughts (via email)

Back to top

Back to homepage