What Is A “Walking Skeleton”?
The older I get, the more metaphors I use stop working over the crowd. Until the recent launch of the new Star Wars series, I lost them at lightsaber.
This “walking skeleton” metaphor, which Alistair Cockburn presented a while back, is based on the old 1920s animated movies. That goes back longer than mine.
In those movies, you see a skeleton walking. As it walks, it adds muscles, skin, and then clothes. All the while, it keeps on walking.
Well, a walking skeleton is a metaphor for a thin start of an end-to-end application. Whatever it is, it’s running from the start. And as we’re adding features, it continues to run.
Now, that’s cool and all, but this doesn’t just happen. You need to create an application like that, so it runs from the first build. It just doesn’t need to do everything.
Here’s an example. As a project for my Automation Testing workshop, the students create a small CI client-server implementation.
On the client-side, there’s an app listening on a project, and if there’s a change in the files, it builds it, runs its tests, and, on success, commits the changes to GitHub. On another computer, the server app listens on GitHub for changes on that same project, then pulls the changes, builds, and runs the tests.
We can wait for the whole thing to be completed and then see it working. But we don’t want to – we want to see something get built incrementally. What does a walking skeleton implementation look like?
Here’s a suggestion. Two apps loading and running. Here’s the first one:
Clicking on the button reports:
(It doesn’t really do anything than report the cheater).
The second one loads like this:
Clicking the button reports:
They don’t do much (obviously), but we can explain the flow, product people can look at the apps and can tell me, “you’re on the right path,” or “that’s not what I wanted.” Effort? Less than an hour. Sunk cost? Minimal.
The next feature added was listening on a pre-defined folder. When we saved a file, the reporting changed (on the client-side). And so on.
As we write more code, we continue to run the apps and see that at least the things from the last demo still work. And as long as we can do that, our skeleton keeps walking.
You can always go back to a version that works. We can always change directions. We can always get feedback. And with small steps, the cost of errors is small.
That’s a walking skeleton. And, believe it or not, it’s not a development-only thing; it works in automation as well.
If you’re into learning more than tools, check out the Automation Workshop.
As well as my upcoming FREE ZOOM WEBINAR on June 28th, “How To Fix A bug?” Don’t forget to register via zoom.
See you there