Walking Skeleton: beginners tips
Have you ever worked for weeks on a new project, finishing all the important cards for the first release, tested everything on your local computer (everything works, of course!), you’re very happy and excited about it but… now it’s time to release: first you will go on a test environment and then, after the tests and fixes, it’s time for production.
This way of working always leads to unexpected problems, many of them related to features created at the beginning of the development and therefore with the developer’s memory not so fresh, in addition to the classic infrastructural problems that arise when we build the environment and put it in communication with other systems (databases, other services, etc.).
A technique to avoid this situation is the Walking Skeleton.
The walking skeleton is nothing else than a small implementation of the system that has only a small end2end feature; it will not use the final architecture but it will have the first connection with all the architectural components of the system so that architecture and functionality will evolve and grow together. We can see it almost as a Proof Of Concept of the architecture.
It’s important to underline that the Walking Skeleton doesn’t make these problems disappear but simply makes them evident from the beginning and distributes them throughout the development, from local to production; in this way, it reduces the complexity in small parts making easier the management of the situations.
Thanks to this approach, all high-risk issues arising from the construction of the automated CI pipeline, execution of automated tests, deployment to staging and production, monitoring, etc. are faced from a very early stage of development.
It is important to emphasize that until the walking skeleton arrives in production (perhaps not visible to the outside world) we are not ready to write the first acceptance test. We want to discover as many potential problems as possible as soon as possible and validate the architecture, getting very early feedback so that it can be improved.
What to expect and what not
Expect
- Only one feature, very simple: depending on the case you can decide to implement a first feature, very simple but actually taken from the backlog; alternatively you can implement a real “hello world” very simple just to bring the walking skeleton to completion (sometimes taken from the backlog, sometimes a hello world)
- Construction of CI/CD architecture and pipelines: many problems related to the architecture, limited to what is necessary to start, and to the automatic pipelines of CI and CD will emerge from the beginning and will be solved in a simpler way thanks to the limited product scope; among these, potentially, we can also include eventual problems of communication with DB or other external systems
Not expect
- A first version that can be released to the public: the Walking Skeleton will lead to the first working (walking) release in production, BUT.. you should not expect a first version “marketable” and therefore publishable and usable by end-users because IT WON’T BE THAT; it is simply a way to build everything you need to get easily into production with the next releases and do it at a time when complexity and pressure are at a minimum
- All problems emerging immediately: we are releasing something very simple, this inevitably makes it unlikely, not to say impossible, that all the problems emerge at this stage; it will not be so and it’s fine like that because thanks to the walking skeleton we have achieved the goal of dividing in a natural way and redistribute this complexity along with the various developments of the features that will arrive
Conclusion
I can only end this piece of blog by suggesting that you try this approach if you never did so: use this technique in your next project in order to see the benefits in practice.
Some references to go deeper:
