I’ve worked on and built several software systems, and a significant frustration I experience is the breaking of expectations.

Mixing software behavior when something is wrong, and when something is right, just leads to frustration. Even worse, something being mostly right, and then unexpectedly being wrong, is the most frustrating for me because I wasn’t expecting it.

We’re human, our software is imperfect, so the above is basically me complaining about not everything being perfect which is a ridiculous thing for me to complain about so let’s accept that some things will be unexpected because humans made things.

Having made the claim that most things being right and then a few things being wrong is “unexpected”, I’d claim that this neglects that most abstractions in business are leaky abstractions. Most of these leaky abstractions were abstracted in simpler times, when there was less money and less customers, or when the users were never consulted.

I’m not mentioning “more time”, because the constant that never changes is that we don’t get more time to work on things. The less money we have, the less time we have to work. The more money we have, the less time the stakeholders have to wait for something.

I’m also not mentioning the phrase “it’s fine, we’ll never need it anyway”: the famous response from stakeholders when they’re told something is more complicated than we thought and we don’t have time in Phase One. The surprise is that they actually do need it, but now you don’t have to worry about it until a frantic rush a week before release.

Anyway, my point is that an abstraction might be both “wrong” and “right” in certain ways, and still always be expected.

To go off on a side-tangent: The curse of working on line-of-business applications is that we always need a grid that provides all sorts of functionality in sorting, filtering, custom grid cells, multi-selection, hover tooltips, input events, ability to say when to trigger UI refresh, general performance problems, etc. Grids have always been a pain in the rear. Many control libraries, even commercial ones, break down in their expectations and abstractions once the grid comes into play. This is a common pain point where expectations aren’t met for the software developer.

I can usually respect a project that does something “wrong”, but does so in an expected manner. How “wrong” something is, can be very subjective in software and ranges from “this button is 1px off” to “mildly inconvenient” to “why in the world would that delete the database?!?!“. There’s certainly an invisible line where its “too wrong” for me to accept or respect. If it’s just a slight inconvenience, it’s probably worth accepting because the cost of deviating is higher than the cost of acceptance.

If you’ve followed along so far, you might notice that I’m almost rephrasing verbatim the Principle of Least Astonishment.

a component of a system should behave in a way that most users will expect it to behave; the behavior should not astonish or surprise users.

or

If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.

This principle of design is most often applied to the user experience, but it applies to the software developer too, as we are users of our own software’s design. And if the design is terrible, we’re going to continually be surprised and feel like the software needs rewriting, which hardly ever actually happens.

To bring up my favorite crutch, I love static analysis of code. I love being told that I’m objectively right by an impartial judge: the analysis tools. The principle of least astonishment for software developers may be upheld by static analysis of code and a strong type system.

Summary

I suppose my point, if I am making one today, is that consistency in software development is a good thing for you, both at your current job and your next job when you inherit someone else’s code.