Binary Thinking in the Real World

It’s an old joke. People say that there are two types of people who understand binary …

We’re not going there. Not today.

Yet there are people in the software development industry who think that computer science and programming shorthand is great for every problem (protip: they aren’t). In this example we can see how computer and binary thinking can be misused in the real world. In this case, it’s a poor way of thinking for showers.

Showers. Indeed.

Real Life Experience

Hotel showers are their own type of hell.

That’s because you might be staying at any given hotel for a night, so you don’t have much time to adjust to a new user interface for a night (when you’re in desperate need of a warm shower). I accept that a shower isn’t the same as manning a space shuttle, but any nuances in the interface can be difficult to adjust to quickly.

When you step into a hotel shower you’re almost guaranteed to encounter one of two designs. You might walk into a precision system where large adjustments lead to small changes after a delay, or you might have a system where small adjustments (after a requisite delay) have no effect but larger movements move the system from Antarctica mode to Surface of the Sun mode.

The delay is probably something to do with plumbing, but since you don’t know which mode you’re in you always have problems. After making an adjustment you wait, and either nothing happens or you’ll be burnt (or frozen). If nothing happens you need to do the same.

There is no middle ground. There is no learning curve. There is only regret.

And every time this happens, I ask the same question.

Who designed this? Why is this so bad?

Software Development issues?

This is where my software developer brain starts to itch.

What we’re really looking at here is a system with poor feedback and terrible granularity. You make an input, then wait. The system eventually responds, but the response is either wildly disproportionate or completely absent. This is a textbook example of how not to design an interface.

In software, we’d recognize this immediately. A slider that doesn’t respond in real time. A button that sometimes works after a delay. An interface where the same action can produce wildly different results depending on invisible internal state.

Nobody would accept this in an app. Yet in the physical world, we somehow tolerate it.

We know better. We spend our working lives deciding whether something should be represented as a boolean, a range, a percentage, or a continuous value. We know that choosing the wrong abstraction leaks straight into the user experience.

And yet, here we are. Naked. Wet. Confused.

Because the second part of software development thinking has taken hold. The type of thinking that means “we can fix this in the next release”, or more accurately in this case “why bother? It works well enough”.

That mindset is familiar to anyone who’s worked in software for long enough. Something isn’t quite right, but it technically functions, so it never quite makes it to the top of the list. It doesn’t crash. It doesn’t block anyone. It’s just annoying. And because annoyance is hard to measure, it’s easy to ignore. Over time, these small compromises stack up and the system still works, but nobody actually enjoys using it.

Annoying isn’t enough

The real issue is that nobody owns “annoying”. There’s no alert for it. No incident report. No customer escalation that forces action.

The issues at play are more than just QA. They’re more than just issues that belong to the product owner. They’re issues of attitude around what we actually produce.

So these products release in a state that no user should need to deal with. Yet we have a culture where updating on release is just “something we do”. So poor quality software (and in this case showers) survive. It ships.

We all know that once software becomes live, it quietly becomes normal. Everyone adapts, works around it, or learns to tolerate it — until nobody even remembers that it could have been better in the first place.

Conclusion

This article was never really about showers.

Because when we confuse “it works” with “it’s good” we sell out a great product. Something might get to good, but it won’t ever become great.

Software developers accept poor feedback, hidden state, and bad abstractions because fixing them doesn’t come with an obvious payoff. We allow those decisions to turn into tech debt. In the real world, they turn into interfaces that punish users for small mistakes.

The outcome is the same either way. Systems that function, but aren’t pleasant to use.

If that sounds familiar, it is because it does.

Somewhere right now there’s a backlog full of things that will move things from “work well enough” into the “work well” category, if only there is time to pick up the ticket. There is never time to action that ticket, and the work never gets done.

I know where that backlog is. It’s at both of our companies. Now we need to do something about it.

About The Author

Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.

The Secret Developer seldom stays at hotels, because what is the point in going anywhere just to use the same laptop?