Writing software for a job you also do

There is a well-known complaint about software in healthcare, and everyone who has worked in a clinic has made it. The systems feel like they were designed by someone who had the workflow described to them once, over a call, by a manager.

Usually that is exactly what happened. It is nobody's fault in particular. The company building the software does not run a clinic, so it asks, and what it gets back is a description. A description is tidier than the real thing, leaves out the parts everyone has stopped noticing, and never includes the workaround somebody invented in 2019 that the whole front desk now depends on.

We are building clinical software, and we also run the operation it is for. That combination is uncommon enough to be worth writing about, mostly because of what it does to the arguments.

The short version of the difference

When a question comes up about how something actually works, we do not schedule a call with a customer. We ask someone downstairs.

The answer usually arrives in about a minute and is usually not what the document said. Not because anyone wrote the document badly, but because the way a job is described and the way it is done drift apart quietly, and only the person doing it knows where.

That is the whole advantage. It is not a methodology and there is nothing clever about it. It is proximity, and proximity is mostly a matter of having decided to be in the same organisation.

What it changes about the software

Fewer features that nobody asked for, because the person who would have to use them is right there and visibly unenthusiastic.

More attention to the parts that are boring and constant. The screens people open forty times a day get more care than the ones that get opened at a demo, which is the opposite of how software tends to get prioritised when the buyer and the user are different people.

And a much shorter argument about whether something is a real problem. In most software companies that debate can run for weeks, because both sides are reasoning from anecdotes. Here it tends to end with somebody walking over and watching.

The uncomfortable part

Being your own customer removes an excuse you did not realise you were relying on.

When the software is late or awkward, there is no client to absorb it. It lands on colleagues, who will tell you, kindly and immediately and every day, until it is fixed. That is healthy and it is not relaxing.

It also makes it very easy to build something that fits us perfectly and nobody else at all. We have caught ourselves designing around a habit that turned out to be one specific person's preference rather than anything the work required. Being close to the user is not the same as being right about users, and the failure mode of proximity is building for an audience of one building.

Why we think it is worth it anyway

Because the alternative is the thing everyone complains about.

Software built at a distance from the work is not bad because the engineers are careless. It is bad because the information arrives pre-flattened, and no amount of care downstream recovers the detail that was lost before anyone started.

We would rather have the awkward version, where the person who has to use the thing can find us.