Find the walking skeleton

Two weeks in, the reconciliation view has a query that works in a test, an endpoint that works in Postman, and a component that works against a fixture. Nothing has ever run end to end. Everyone would tell you the project is going well, and everyone would be guessing.

Alistair Cockburn’s definition is narrower and more useful than the version that gets repeated:

“A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components.”

The important half is the second sentence. This is not about delivering user value early, which is move twelve’s argument. It is about the day your architectural components are wired together, which is a different date and usually a much later one.

The thing that makes it a skeleton and not a spike

Cockburn is explicit about the distinction, and it is the whole chapter:

“A spike is ‘the smallest implementation that demonstrates plausible technical success.’ The spike typically takes between a few hours and a few days to complete, and is thrown away afterwards.”

A skeleton is not thrown away. It is production code, with tests, that stays running for the rest of the project. Everything else grows on it.

Which gives you the standing rule this move actually contributes. Cockburn describes his own project, systems passing messages around a ring: the technical leads decided to connect them in the first week so a single message could travel the whole loop, and then to keep that working every week afterwards.

That second commitment is the one people skip. Connecting things once is a demo. Keeping them connected is an architecture.

WHAT IT IS, CONCRETELY            THE RULE THAT MAKES IT WORTH IT

 client-server                     it is production code, not a spike
   one screen, to the database,     it has regression tests
   and back                         it runs in CI from week one
                                    it is never allowed to go red
 multi-tier or multi-platform         for more than a day
   a working connection
   across the tiers                  from that week on, "does it
                                     connect?" is answered by a build
 message-passing systems             rather than by an opinion
   one message travelling
   the whole ring

Cockburn’s own examples, and none of them is a feature. A screen to the database and back does not do anything a user wants. It proves the wire exists.

The move

In the first week, make one trivial thing travel the entire system, then never let that stop working.

The same idea has other names

Worth knowing, because you will meet them and wonder whether they are different things. Cockburn says they are not: the Poppendiecks call it a spanning application, and Hunt and Thomas call it tracer bullets.

The Pragmatic Programmer tip is a good one to keep: use tracer bullets to find the target, because they “let you home in on your target by trying things and seeing how close they land.” And their neighbouring tip draws exactly Cockburn’s line, from the other side: prototype to learn, where “the value lies not in the code you produce, but in the lessons you learn.”

That is the whole taxonomy. Prototypes and spikes are for learning and get deleted. A skeleton is for connecting and gets kept.

What it costs

No measured evidence supports end-to-end-first over layer-first. I could not find any, and I am not going to imply it exists. The argument here is about when you discover integration problems, not about a demonstrated improvement in outcomes.

It front-loads the least satisfying work. Week one is deployment configuration, environment variables, a certificate, and the ninety minutes where nothing works for a reason that turns out to be a trailing slash. There is nothing to show for it except a build that passes, and you will be asked what you have been doing.

And it can calcify. A skeleton built to link components “need not use the final architecture”, in Cockburn’s words, but skeletons have a way of becoming the final architecture by inertia. Write down which parts were expedient, or the temporary auth shim will still be there in two years.

Try this week

Ask one question about the thing you are currently building: has anything at all travelled from the real front end, through the real API, to the real database, and back, in the real deployed environment?

If the answer is no, that is this week’s work, and it does not matter what it carries. A hardcoded string. A hello. One row that always says the same thing.

Then wire it into CI so that it runs on every commit, and treat it as broken-build-level urgent when it fails.

You will have replaced the most common question on a software project, is it nearly working?, with a build status. That question has never once been answered accurately by a human being.