Design by cliché

“Woman photocopying her face” licensed via iStock

I want to propose the term design by cliché for the software architecture anti-pattern of trying to arrange things based on what they are called, not what they do.

In this post I will share an example of design by cliché and some ideas about why and how it happens, and I’ll invite you to recognise it so you can resist it.

“Booking” vs “Booking”

The national vaccination and screening programmes we operate require patients to attend appointments.

We recently reversed a decision to build a “platform” that would first arrange “capabilities” like “booking” so that the various services could be assembled from these pieces.

We have appointments, went the “platform” logic, so we require “booking”.

But what “booking” means can vary wildly from service to service. Two thirds of breast screening appointments are administered via mobile vans. This is a different, and differently-complex, sense of “booking” from clinic-based appointments, and different in turn from “booking” a vaccination in a community pharmacy.

These “bookings” have little more in common than a name. And indeed that is exactly what teams at the Ministry of Justice found when they tried to standardise “bookings” for prisons.

“Booking” is a cliché, a word with all the meaning worn out of it.

So I propose that the true name of these evidence-free simplifications is design by cliché and I propose it so that we can name it and stop it where we see it.

Prove it

Like you I have felt the complicated urge to simplify the world through the system rather than accept the world’s complexity into the system. Every project has to balance those forces, but to run for cliché from day one—which is to assume the world will bend for you—is unlikely to be successful or cost-effective.

Even so, I often find myself in discussions where the burden of proof is placed on me and my teams when we argue that a “booking capability” is not a good fit for reality and also that it has no automatic right to be a good fit.

It seems to me that the more moderate position is to assume that the world we need to model will be more complicated and diverse than we know at the start. That is the foundation of the test and learn approach we follow.

The burden of proof actually lies with whoever wants to jam such a radical simplification into our world model.

For the love of cliché

A cliché-driven design looks equally well when it dresses as a proposed “generic” internal capability or as a commercial “solution” ready to procure. It will be stunningly attractive to the right audience.

Five ideas about why.

Firstly, all clichés provide comfort and certainty.

Secondly, as with the drunk man looking for his keys under the streetlamp “because that’s where the light is”, the mere existence of a word for a suitable-seeming concept means we’re likely to see it as a plausible abstraction.

Thirdly, I’ve noticed people often mistake the wish for a coherent user experience for the wish for a “neat and tidy” software system design. Of course, if users arrive expecting consistent user interfaces (and they have a right to!) those are for interface design patterns and design systems to provide. Software architecture plays at most a supporting role.

Fourthly, once the simplified world model—the mediamacro that is built out of clichés—takes hold, failing to enforce its supporting clichés can feel like a failure of leadership. “It’s just booking! Why can’t we do something as basic as booking!?” And then one buys a “booking” “solution”, even though “booking” doesn’t exist.

Finally, we live in a market where clichés are offered. These “solutions” give us a way to invest directly in our wishful worldview. And they look like thrift because they resemble economies of scale: one thing for many things.

Of course spending money does not make something real. You can buy a thing called “security” instead of security itself. Again, the burden of proof should be on those who wish to do that, not those who wish to question it.

Politics

In the public sector clichés can and do take hold in political language, forming a vicious cycle that runs through campaign speeches, through citizens’ expectations, and right down into the bits and pieces of the software we build or procure by cliché, whose accordingly poor performance invites further calls for simplification.

Wherever reality cannot push back on cliché, the spiral will get worse. But reality will eventually reassert itself through the unwelcome force of system failure. At the very least, one day the money for clichés will run out.

Unfortunately that is the same money we need to spend on real problems.

Thanks to Sarah Fisher, Dan Bower, James Darling and Richard Pope for their feedback on an early draft of this post.