On consistency

When you talk about software development approaches you often find people advocate consistency, in a unsubstantiated way, the way people advocate 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 that it should be understood as something in service of more primary objectives. And additionally that naively pursued it can actually be harmful.

Inconsistency can work

Let's start with a 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 viewing from 2022. Then later we added a Webpack setup that allowed for a fairly decent developer experience. 3 completely inconsistent approaches. Yet all delivered value and worked reliably. There were certainly costs, but the only major one was for new starters trying to explain our apparently awful, inconsistent legacy setup.

I think back to this and some other examples when people are naively advocating consistency. Here was an example where inconsistency worked (the code ran reliably, we didn't need to work on it); indeed one where 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. While you might have made the cost of some global changes small (though often even this is overstated as now the blast radius of changes is much larger), 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 get a lot more complex to support all the use cases. Future development of this 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 have autocomplete, some are really filters, some are 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 who each 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 don't 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) will mean a tailored, specific implementation. This is of course at odds with consistency. Like in some many parts of software you must balance these two and other dimensions.

Consistency means less learning

For individuals and for organisations, 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 be that too, but the real problem might just be that it is actually 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 (colours, sizes and so on), though things like TailwindCSS can do this out of 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 a established UI library.

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