Hacker News new | ask | show | jobs
by 0xbadcafebee 860 days ago
I think this kind of misses the point. Yes, programmers are bad at managing state. But programmers aren't managing state, the programs they write are. Programmers are bad at programming.

This isn't hard to understand at a fundamental level. Ask a programmer to write one simple algorithm during an interview, and there can be dozens of different bugs found. Modern software is made up of millions of these algorithms. So the potential for bugs is massive. There's simply too many things to think about, and you can't see all the invisible gotchas. We like to think of ourselves as "computer geniuses", these incredibly smart and talented humans who have an unlimited capacity. But that's just false. We're fallible in general, and software isn't an exception to that.

This is made worse by the fact that there are no "building codes" for software. In physical engineering, there are all kinds of requirements to build something. You must use 10d nails for this kind of wall, spaced at 16 inches, with 2x4 studs, etc, to build a given kind of wall for a given kind of building. You're not allowed to skip them because "you don't think this needs to scale". On the other hand, adding things unnecessarily just drives up cost and makes things take longer. But we software engineers get to literally do whatever we want (and often do), with the excuse that "it's not gonna kill anybody!" But people rely on the software we write for every task in their lives today. We tell ourselves that we don't need to care how we do our jobs, which results in things like avoidable defects, and an unnecessary increase in time and money, and difficulty in just getting things done with software products.

There is a simple solution to "managing state": versioned immutability. Basically, you look at something in a given state, and if it's working, you say "ok, take a snapshot of that state and give it version 1.0". Later, when the state naturally devolves into chaos, you say "ok, restore state version 1.0". This is essentially a hack to deal with the fact that we suck at making programs that can deal with entropy. But it's a hack that tends to work.

In the Operations space, we've long since learned that immutability is the only simple way to make systems reliable. You can build incredibly complex configuration and state management systems to constantly try to "fix" state by poking and prodding the state back to where you'd like it to be. Or you can just... restore a backup. Kill the current thing and replace it with the old working copy. That's Immutable Infrastructure, and it's the single most powerful idea we've had for managing systems in at least 30 years.

More software developers need to understand this principle and start applying it to the code they write. For example, Cloud-based services that provide no means for immutable management tend to be difficult to manage, and require complex configuration management tools like Terraform to constantly "fix" their state.

The flaw isn't that the state can change - it's that the state can change into a "bad" state. We can't predict what that state will be, because again, we're bad at programming. But we can tell when the state was "good", and go back to that when things stop working.

To facilitate that, a system needs to have a concept of the conditions under which it operates, and the actions taken under a given state. An example is a web app. When the web app state is "good", it can do things like process user registrations, display content, perform transactions. But when the app state is "bad", it can no longer perform the actions properly. The difference between the states is an operational state; the state which determines if the app can perform its function. Outside of that is the state of the individual actions, which will of course change during the course of the action (to perform a user registration, there must be state changes like "add a user to the database"). So software systems need to have a distinction between the kinds of state that affect operations or not, and version those, and allow easily restoring those versions.

1 comments

> there are no building codes for software

There are all sorts of standards...ODBC, SOC II, ISO 27001, POSIX, Unicode, HIPAA, ISO 8601, SOAP, GDPR, JSON-API, W3C, OCI, etc.

Codes coming out the ears.

Those aren't really like building codes. Building codes are effectively minimum specifications for safety, with the requirement that they can be inspected and approved. The codes eventually became more uniform, but their original intent was to prevent shoddy workmanship from creating hazardous conditions.

SOC II and ISO 27001 have to do with security, which is close to safety, but not the same. GDPR and HIPAA are concerned with privacy, which is more related to security than safety. The rest are about compatibility.

If somebody breaks into a building, that's a security issue. If the building falls down, that's a safety issue. Software can be secure, private, and compatible, and still crash all the time. Safety isn't the same as reliability, but safety tends to lead to reliability, because if it wasn't reliable, it wouldn't be all that safe.

So I think we could use standards that focus more on safety [and reliability]. It won't make the products make more money - in fact, it'll cost more to make them. But the result will be better for people and society overall, the way building codes have been.

> their original intent was to prevent shoddy workmanship from creating hazardous conditions

And therein lies the difference...a building collapsing will kill its tenants. Software collapsing will make someone late for dinner.

When software is critical, there are safety standards: DO-178C, DO-330, ISO 13485, ISO 14971, etc.

Software has significant effects on people that isn't immediately apparent to the designers.

I'm sure that the contractors who designed accounting software for the UK Post Office didn't expect to ruin the lives of hundreds of people. https://www.bbc.com/news/business-56718036

I'm sure the designers of Facebook didn't mean to inspire a mental health crisis for young people. https://www.sciencenews.org/article/social-media-teens-menta...

I'm sure the designers of GPS software didn't mean for hundreds of people to drive into lakes while blindly following the GPS. https://duckduckgo.com/?t=ftsa&q=google+maps+errors+lead+to+...

I'm sure the designers of predictive policing software didn't mean to racially discriminate. https://www.technologyreview.com/2020/07/17/1005396/predicti... Same for facial recognition software. https://jolt.law.harvard.edu/digest/why-racial-bias-is-preva...

The longer that we continue to be flippant about the impact of software on the lives of people, the longer people will suffer due to our laziness and unprofessionalism.