I actually don’t like this XKCD, this is a bad answer to why electronic voting is bad.
Mostly because it is a largely obtuse process that most people can’t see or understand.
“Trust the magic rock is counting fairly and that bad people who would want to manipulate it in order to obtain power and conquer you haven’t had a chance to do so.” You cannot code your way out of that.
Everyone understands marks on paper. No one understands buffer overrun RCE, resistive touchscreen calibration, or database triggers and log sharding.
While I see what you’re getting at, I still like this XKCD. I work as a developer, and have also worked in more “handy” fields. The thing with planes, elevators, and basically all other physical things is that they’re limited by physics. A steel beam can’t suddenly decide to spontaneously fail or disappear.
With code, that can feel pretty different. With experience, I’ve basically learned to assume that there is always some edge-case I haven’t considered, that could trigger a bug. In a building, you can have redundant bolts, and over-dimensioned supports. A small mistake somewhere, a single missing bolt, won’t cause a catastrophic failure. With code, it’s different: A tiny, hard to notice mistake, can bring the whole think crashing down. Imagine if a plane could crash because the paint had a slightly non-uniform thickness…
This is exactly the kind of thing I’m talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear.
Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection…
as xkcd put it:
I actually don’t like this XKCD, this is a bad answer to why electronic voting is bad.
Mostly because it is a largely obtuse process that most people can’t see or understand.
“Trust the magic rock is counting fairly and that bad people who would want to manipulate it in order to obtain power and conquer you haven’t had a chance to do so.” You cannot code your way out of that.
Everyone understands marks on paper. No one understands buffer overrun RCE, resistive touchscreen calibration, or database triggers and log sharding.
I understand log sharting!
While I see what you’re getting at, I still like this XKCD. I work as a developer, and have also worked in more “handy” fields. The thing with planes, elevators, and basically all other physical things is that they’re limited by physics. A steel beam can’t suddenly decide to spontaneously fail or disappear.
With code, that can feel pretty different. With experience, I’ve basically learned to assume that there is always some edge-case I haven’t considered, that could trigger a bug. In a building, you can have redundant bolts, and over-dimensioned supports. A small mistake somewhere, a single missing bolt, won’t cause a catastrophic failure. With code, it’s different: A tiny, hard to notice mistake, can bring the whole think crashing down. Imagine if a plane could crash because the paint had a slightly non-uniform thickness…
A good example of software failing where traditional systems were more reliable is when Boeing tried to rely on it with MCAS on the 737 max
This is exactly the kind of thing I’m talking about. You can confirm the structural integrity of the wings with a rather simple visual inspection. Same goes for the windows and landing gear.
Try confirming the integrity of (tens- or hundreds of) thousands of lines of code with a similar kind of inspection…