Your product is a function

Successful design is not the achievement of perfection but the minimization and accommodation of imperfection.

H. Petroski — "To Engineer Is Human"

We almost always describe products with nouns. A dashboard, a CRM, a marketplace, an expenses app. And we describe features with more nouns: a filter, an export, an alert, a search box.

Nouns have a dangerous property: they invite catalogues. They can be piled up without limit because adding a noun to a list does not break the list. Hence that literary genre so characteristic of our industry, the feature comparison in columns, where the product with more ticks wins.

There is another way of putting it, and it changes a good deal. A product is a function: it takes a situation and returns an outcome. What is interesting is not the list of what it contains, but the transformation it performs and the set of situations for which that transformation is defined.

The domain is what almost nobody declares

When you think in terms of a function, a question immediately appears that a catalogue never forces on you: for which inputs is it defined?

That is where most products break. Not in the transformation, which is usually well built, but in the domain. The function works; it is simply not defined for the situations people are in. It was built with the clean case in mind — the user who has all the data, the right permissions, a complete process and a single thing to do — and it behaves arbitrarily the moment any of the circumstances that make up actual working life turn up: the half-finished file, the customer who fits no category, the person covering someone else's job over a holiday.

Those edges are not exceptions. They are most of the volume. A product can pass all its tests and be useless, because every test was written inside the domain where it was already known to work.

Declaring the domain has a political virtue too. A product that says out loud which situations it serves can also say which it does not, and that is the only thing that makes it possible to refuse something without appearing lazy. With no declared function, every request is equally legitimate, and the backlog becomes a warehouse.

Petroski and administered imperfection

Petroski's line says something that is obvious in civil engineering and that we in software still deny: design does not consist of achieving perfection, but of minimising and accommodating imperfection.

Accommodating is the important word. It does not say eliminate. It says build the place where imperfection is going to live without destroying the rest. A bridge is designed in the knowledge that it will deform, and the joint that permits that deformation is designed too. Imperfection is not fought: it is given somewhere to be.

Engineering learned this because bridges fall down and collapses get investigated. Software has a plasticity that lets it escape that reckoning: you can always ship a patch that same afternoon. The consequence is not that we have less imperfection, but that we never get around to building it any accommodation. We keep applying patches where there should have been a joint, and three years later what exists is a geological layer of exceptions nobody can read.

Applied to the function: the point is not that the domain should be infinite. The point is deciding what happens when the input falls outside it. A well-made product is not one that never receives an unforeseen situation; it is one that, when it does, does something comprehensible with it.

Functions compose

There is a final advantage, the one I value most and the one we handle worst.

Functions combine. It is the principle the Unix tradition was built on: do one thing well, and leave it in a state where somebody else can chain it to something you never anticipated. A program defined by what it transforms can be part of a chain. A program defined by what it contains can only grow.

Products follow the same rule. Those defined by their catalogue can only be extended, and their way of responding to the market is to add. Those defined by their function can enter compositions they never imagined, and that capacity is more valuable now than ever, when any product is going to end up being invoked by an agent that never read its marketing documentation.

It is worth doing the exercise with whatever you have in hand. Write in one sentence what your product transforms, without naming a single screen. If you cannot, you have a catalogue. And the nature of digital products does not forgive catalogues: they grow until nobody remembers what any of it was about.