In fact, if you try to close a door that is locked, you’ll put a large dent in the door jamb. So this combination is not only sensical but desirable to detect.

Perhaps a better lesson is to not be overzealous when paring down your logical model.

I thought the same thing. And now the "locked" enum state doesn't just mean locked, it means closed AND locked. And I don't actually like it when an enum value implies multiple things.

All mental models fail to represent the real world completely. That’s kind of a fundamental feature of them.

Yes, because they are focused on the relevant parts for solving a specific problem.

So one could say that the article's fundamental flaw is not explaining what is the purpose of the model, therefore we cannot assess if it is capturing the relevant aspects to solve the problem.

And by examining the model, we discovered a flaw in our understanding, that doors can lock open, which is maybe undesired or dangerous. So this model was successful.

But if the model doesn't reflect reality, then reality breaks the software. That's how bugs happen.

Which means that the non buggy model that best reflect reality, and covers all possible scenarios that will happen in production is the two boolean one, not the enum.

> which is maybe undesired or dangerous

Or desired. Perhaps the user had the need to keep the door from shutting and didn't have a wedge at hand.

Which has its own unexpected bug in that the extended deadbolt can damage the wood frame and/or trim. Or perhaps the sensor you use to determine the door's state (open or closed) is positioned on the hinge side in such a way that it's triggered when the door is kept open with the deadlock extended. It's close enough to closed that the sensor gets triggered, and you--I can't help myself--open the door to the possibility that your system falsely represents the door as being both closed and locked.

This stuff can be hard, and sometimes, you just have to refactor later on instead of trying to nail down every possibility for the model, despite trying to figure out likely issues in the near-term. In which case, the goal is to keep in mind that data models will eventually change over time, and consider how that knowledge might change what you're writing now to make that process less painful.

> Which has its own unexpected bug in that the extended deadbolt can damage the wood frame and/or trim.

It doesn't. The data is correctly representing the state of the system. Your "bug" assumes a lot of things about the environment, any of which may or may not be true depending on the specifics where the system is running.

> Or perhaps the sensor you use to determine the door's state (open or closed) is positioned on the hinge side in such a way that it's triggered when the door is kept open with the deadlock extended.

Again, an implementation problem. The sensor was installed in a way that's incompatible with the underlying system. Can it be fixed by changing the data model? Unlikely. In fact, I don't think it can be fixed at all. If the sensor lies, there's nothing the underlying system or the data model can do about it, especially if it's a binary sensor like the one described.

If the deadbolt was installed in such a way that it never crossed into the door frame but rather only moved inside the actual door, would you consider it a bug in the lock, the deadbolt, or simply bad installation?

Exactly! Beat me to it.

This is a constant source of bugs in software: developer making a "reasonable" judgement that gets crushed by reality.

The core idea is true, though. Enumeration types, set operations and pattern matching are must-have features in any PL.

And you need that state in the game Grim Fandango (spoiler) to solve a puzzle: lock an open door before the maintenance demon leaves. Then when he leaves he’ll close the door. But it won’t be close. So you can get inside.

> Yes, you can't close a door that is open but the lock is turned.

That depends. If it's a deadbolt, you're correct. If it's the lock in a doorknob, you probably can. This is typically how I lock my front door when I leave, I lock it then close it. Cars doors can also generally be locked then closed.

I like booleans, sometimes when I'm starting those nested if statements, I'll just go ahead and take the cases, enumerate all of the conditions in a "truth table" and write code accordingly for each case. The best thing about this is that you see all of the cases and can spot the undesirable or invalid cases and plan for them. Just like the article says, you spot an odd case (door locked but open) and can get a "heads up". The only thing is that the article seems to be against booleans so watch out for just enumerating the cases you expect because as mentioned, those "door locked but open" cases could actually be possible but unexpected.