On Consistency

When discussing software development approaches, people often advocate for consistency in an unsubstantiated manner, similar to how some advocate for semantic CSS. Worse, it is not even clear what they are talking about. Here, I will argue it is overrated. Not that it can't be important, but it should be understood as something in service of more primary objectives. Additionally, when naively pursued, it can actually be harmful.

Inconsistency can work

Let's start with an experience I had over a period of years working on a code base at a startup. Our frontend code started with jQuery-ish stuff that was standard on Rails at the time. We then added React, in a pretty horrible way, at least viewed from 2022. Then later, we added a Webpack setup that allowed for a fairly decent developer experience. Three completely inconsistent approaches, yet all delivered value and worked reliably. There were certainly costs, but the only major one was for new hires trying to understand our apparently awful, inconsistent legacy setup.

I think back to this and other examples when people naively advocate for consistency. Here was an example where inconsistency worked (the code ran reliably; we didn't need to work on it). In fact, stopping new feature development to make things consistent would almost certainly have been a terrible idea. We'd likely have introduced bugs, and it would have slowed down business.

Experimentation

Another problem with consistency, especially premature consistency, is that you will likely find yourself stuck at a local optimum. You might have made the cost of some global changes small (though often even this is overstated, as the blast radius of changes is much larger). However, it will be very hard to make major changes. Having several approaches allows you to consider substantial alternatives. At the very least, it will help you understand the current approach(es) better.

Coupling and Complexity

Consistency can introduce a lot of coupling, as many parts of a system will use a single component. That component will likely have to become much more complex to support all the use cases. Future development of such components will get harder and harder.

I remember hearing a story about how a large company had, let's say, 15 different search boxes. That sounds bad, but I suspect it wasn't that terrible. Probably some had autocomplete, some were really filters, some were a Google-style box, and so on. While I doubt there were really 15 different boxes, it was probably some n > 4 of them. Each was likely owned by a different team that didn't have to worry about the other teams as they iterated. Visual inconsistency might have been an issue, but there are simple ways to address that that do not require a single implementation. Also, visual inconsistency, while not desirable, is a great deal better than something not working at all.

Consistency means using less optimal solutions

To achieve the optimal solution to any given problem (assuming that is even clear) requires a tailored, specific implementation. This is, of course, at odds with consistency. Like in so many parts of software, you must balance these two and other dimensions.

Consistency means less learning

For individuals and for organizations, if things are too consistent, they learn less. Trivially, any A/B test is inconsistency.

Consistency is never a primary goal

Sometimes people talk about consistency as if it is an extremely important, primary goal. It is not.

The primary goal of most projects is something like sustainably deliver business value (where business might include conventional businesses, charity work or something else).

The two things that seem to sit below that are UX and DX. If we are going to deliver some value there will have to be some kind of UX. If we are going to deliver anything there must be a reasonable DX. Improved DX facilitates work to improve value delivery.

Consistency can be a part of both of those, but often quite a small part.

Some of the things people think are inconsistency are something else

Often, I've seen poor encapsulation or poor-quality code condemned as "inconsistent". It might also be inconsistent, but the real problem might be that it is simply bad. Most code is. This can be because it was carelessly or unskillfully created, or because things have changed (as they usually do).

How to manage inconsistency

Delete-ability (and encapsulation)

One of the most desirable qualities in a component is delete-ability. That means it must be relatively uncoupled. It must have clear boundaries. It probably means it is easy to change. If something is truly delete-able then inconsistency is likely to have few negatives, and a lot of potential positives in discovering new or improved approaches.

Lifecycle

For parts of systems, have some way to track the maturity of components. There should be some way to do new, experimental work, and other parts which are more ossified. Don't try to jump to the final state in order to achieve consistency; you don't understand the problems well enough for that yet.

Where to prioritise Consistency

Some areas are low cost but high benefit. For example:

• Design tokens (colors, sizes, and so on), though things like TailwindCSS can do this out-of-the-box.
• Formatting or data processing logic (you really don't want to have lots of slightly different versions of this).

Others are moderate benefit—for example, basic UI components for text or layout—but again, low cost.

You can also piggyback on someone else's consistency (and all their battle testing) for more complex UI by using an established UI library.

For newer developers, a simple, consistent approach may be important. This might mean ignoring quality to some extent, but keeping things simple can be important until people gain more experience.