Change is the root of all (evil) bugs
5 points by abnercoimbre
5 points by abnercoimbre
And I always thought bugs were caused by an inattention to detail (and the Devil is always in the details).
This is why:
a) a thorough version history of all dependencies, configurations, and network changes is key. b) the abiltiy to roll back to a known-good state is the best defense.
We are starting to have the tools to manage both these things, and hopefully those tools become better, more widespread, and easier to use.
Does Nix figure into your calculation here?
Nix is one of the tools we have in our new toolbox. I haven't personally used it, but I can definitely see how it would be useful
This reads a bit to me like saying "reality is the root of all bugs".
change is the only constant, and should be embraced, or at least acknowledged and respected. this is why software is eating the world, or destroying the world.
software is called software because it differs from hardware in that it is easy to change - relatively speaking. if you build hardware, whether for manufacturing, automobiles, doing math, crushing rocks, or rendering doom clones, those are hard to change. even today with over the air updates and flexible runtimes and systems that actually can update themselves to an extent.
if you build good software, it can be changed just by tweaking a few lines of magic incantation and deploying, or changing an env var or config file and restarting, or changing the runtime on the fly (well, smalltalk could do it). the best places i've worked deployed hundreds of times a day, without much incident. it was normal. and I know that is probably trivial considered to the most advanced eng orgs now.
some of my favorite experiences in building software is when someone reports a bug or annoyance that was ruining their week, and i could change it with a one-line fix and a single deploy [app] to prod command. that is also the power of change.
change also leads to suffering, as your resident grey-beard buddha will tell ya. but the ever-present feeling in much of our field that "change is bad" or something to be "managed" is a curse and a straitjacket. it limits the scope of the possible.
sure, use tools to reduce the risk and pain of unwanted change: git, nix, immutable data, functional programming, browse the web via lynx, whatever works! I get all that. but don't forget that software's malleability is also a strength, and much of the joy (and privilege and $$) we get from this silly technology comes from that.
Just finished reading Cory's latest missive, and he makes the point
Because that's the thing: any nontrivial code has to interact with the outside world, and the outside world isn't static, it's dynamic. The outside world busts through the assumptions made by software authors all the time and every time it does, the software needs to be fixed.
from https://pluralistic.net/2026/01/06/1000x-liability/#graceful-failure-modes
There's a lot in there, where he tries to differentiate between two disciplines of "writing code", which is the pure act of integrating a set of instructions and algorithms into a language so specific a computer could use them to solve problems, and "software engineering", which is the act of integrating the above-specified code into the big wide messy world, which includes change.