This blog post became popular recently: How Many Values Does a Boolean Have?
The author approaches the question from a fairly detailed technical perspective. They're talking about things like nullability and encoding values as an int. That's cool but not quite my own perspective.
I am a line of business software developer. I sit down with managers, directors, and team leads who own business processes. We try to figure out how to scale up what they're doing to a slightly higher level. Think excel documents becoming low-code apps, or low-code apps becoming full blown web apps. I spend as much time thinking like a business person as I do thinking like a programmer.
When I think of the question "how many values does a boolean have?" here's some of the more esoteric possibilities that come to mind.
-
True or false, but only because we kind of generally assume that's the default, and nobody ever bothered to set this value consciously, so it's only set this way because that's the initial answer.
-
True, because some other property of the business object constrains this boolean property, so we don't even let the user edit this anyway. It "has to be" true in this case.
-
False, because some business rule has run (which one? when?), and set it this way. Nobody has manually set it this way.
-
True, because somebody uploaded a bulk file of data and overwrote this and lots of other values in one big dump.
-
Blank, because we don't know what it should be, and we've never known, because nobody has ever set it before, and our system doesn't default to true or false.
-
Unknown, because somebody came in and deliberately set this property to "we don't know". It's not blank because it happens to be blank, it's blank because somebody consciously set it to be unknown.
I could keep going. You get the idea. Depending on what your role in software development is, you might get sent in a different direction by this question.