Walking Skeleton
The Walking Skeleton aims to lay a solid foundation for reaching the MVP while minimizing technical debt. It’s a step worth formalizing.
It’s not clear whether Alistair Cockburn chose the best metaphor when he conceptualized this stage of software development, given that skeletons have an unfortunate tendency to be scary… However, the metaphor works if we consider that the bones embody the software’s architecture, while the missing flesh represents its functionality.
Laying a Solid Foundation to Minimize Technical Debt
Here is the definition of a Walking Skeleton:
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 architecture and the functionality can then evolve in parallel.
In other words, the specific functionality in question doesn’t matter. It’s merely a pretext for laying the groundwork—solid technical foundations—upon which future features will be built. The better the foundations, the easier it will be to develop those features. It’s both a matter of managing technical debt and of Developer Experience (DX).
The Walking Skeleton falls between the PoC (or possibly multiple PoCs) and the MVP, which represents a substantial amount of work—at least if we agree with this definition. But even without adhering to this definition, there will come a time when you decide to build something “solid,” and at that point, the Walking Skeleton approach will come into play.
Non-exhaustive list of topics to cover
In practical terms, this means addressing at least the following topics:
- The architecture, necessarily “as of today” (we’ll come back to this shortly);
- Authentication and permissions management;
- More broadly, all security best practices (e.g., defensive programming);
- Naming and style conventions (their absence creates inconsistencies, and thus technical debt);
- Testing and coding practices (including Test-Driven Development);
- Implementing CI/CD (the more painful it is, the more you need to plan ahead);
- Log management in production (essential for debugging);
- To this, I would gladly add the implementation of the Design System, if that hasn’t already been done;
- etc.
The idea is to enable production-ready development later on: you don’t want to discover all these issues when it’s time to go into production (adding 3 months to the timeline) or while already in production (technical debt, security vulnerabilities).
In the definition above, the phrase “evolve in parallel” is key: it would indeed be unrealistic to try to set all these decisions in stone. Sooner or later, new features will introduce new constraints, which will lead the team to adjust some decisions at the margin.
An opportunity to document your architectural decisions
To ensure this goes smoothly, the team would be wise to create an Architecture Decision Record (ADR) when setting up the Walking Skeleton. The ADR outlines the rationale behind each decision, which prevents the same issues from being brought up repeatedly. Indeed, if the context hasn’t changed and it’s delivering results, a decision should not be called into question.
On closer inspection, many teams end up implementing a Walking Skeleton without really realizing it when the first “major” features come into play. Alistair Cockburn—the very same person behind Hexagonal Architecture—deserves credit for making the approach explicit and, in doing so, separating it from the implementation of features.