Most failures happen between systems

The software that fails is rarely the software that was written. It fails where two systems meet, and that is the part nobody was asked to test.

A company buying software usually buys a thing: a system that does a job. The job gets described, the thing gets built, the thing gets checked against the description. By that measure most projects succeed. The system does what it was asked to do.

Then it is put next to the systems the company already runs, and the trouble starts.

The seam is the part nobody tested

Every system in a business is tested on its own terms. The accounting software is correct about accounting. The store is correct about orders. The customer record is correct about customers. Each was checked by the people who built it, against the job it was built for, and each one passes.

The place where two of them meet was built by neither. It is a field mapped to another field, an export that runs at night, a rule about which side wins when both have changed since yesterday. It has no owner, no test, and usually no document.

The seam is the least examined part of the system and the part most likely to be wrong.

What it looks like when it fails

It rarely fails loudly. A record exists in two places and the two disagree. A field means one thing on one side and something slightly different on the other, and nobody notices until a report is wrong. A step assumes a person will carry the information across, and it works until that person is away.

The company does not experience any of this as a software failure. It experiences it as a period during which nobody is certain which number is right.

What follows from taking it seriously

Four things, and each is a decision made before code is written rather than a correction made after.

  1. Scope is bounded by writing down what phase one does not include, before phase one starts. A list of what is being built is not a boundary.
  2. Migration is treated as the engagement rather than as its last week. The state before the move is kept, and stays restorable.
  3. The client owns the source, the schema and the deployment pipeline from the first commit, not at handover.
  4. Permissions are decided while the system is being designed. Who may see what is a structural question, and answering it after launch means changing the shape of the thing.

None of these make the seam simple. They make it something with an owner, a written state, and a way back.