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. I discovered the same with the walking skeleton.
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 print the message, the cheater).
The second one loads like this:
Clicking the button reports:
(It doesn’t really do anything than print the message, the other cheater).
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. Obviously, with each one, we also add automated tests that check the added features (although in this example, we checked manually).
We can always go back to a version that worked before. 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. It can always be done, it’s just a matter of deciding
- We’re going to start with a thin, automatically built, tested doing almost nothing.
- We’ll add small (even smaller!) working, tested features
- Repeat.
If you’re into learning not just tools, but also for how to build always working software, check out my Automation Workshop.
0 Comments