Prototyping vs. Walking Skeleton

“Please check if the feature can be implemented at all. And give me your result as soon as possible.” – one way or another, a software developer might be asked to implement a prototype. Most software developers have probably already implemented prototypes, either to quickly try out project ideas or to find out if there are any technical obstacles during implementation. Prototype development is a great tool that provides important insights without investing a lot of time.

However, prototypes have a bitter aftertaste in daily practice that is often ignored in organisations: A prototype is a disposable product, a “let’s make it work and we can show what it can do” software. This throw-away aspect is often ignored and prototypes are integrated into existing solutions again and again. Of course, such an integration is not without consequences: subsequent error corrections, additional development costs, dissatisfied users – just to name a few disadvantages. A possible alternative to prototyping with disposable products as a result is the so-called walking skeleton.

The prototyping

The term prototyping is interpreted differently in different industries. Usually, prototyping means that you want to get an idea or a technical implementation up and running as quickly as possible in order to evaluate its feasibility. A distinction is made between exploratory, experimental or evolutionary prototyping. Exploratory prototyping is about the step-by-step clarification of requirements and the refinement of the prototype. The prototype as such is the result of prototyping and prototyping is a process. Experimental prototyping should provide proof of feasibility before actual implementation. In the practice of a software developer, it often happens that requirements for a feature are not yet completely clarified because the clients or users themselves do not yet know what exactly they want. Organisations regularly find it difficult to establish a defined process in requirements management. The presentation of a prototype helps to better understand requirements. The client can see whether a development is moving in the desired direction, and a user can experience whether the operation is as easy as hoped for. The prototype thus becomes a proof of concept.

Evolutionary prototyping goes one step further and pursues another goal: it aims to develop the prototype to product maturity through regular feedback from future users. This prototyping approach thus differs at most from the other two. The disposable aspect described here theoretically only exists here if the initial prototype clearly misses the development theme and it makes more sense to replace it with a completely new prototype.

In my personal experience, prototyping is always a fantastic tool when it comes to finding and presenting solutions quickly. It can be used to specify and verify requirements, reduce the risk of misguided developments and also integrate quality assurance at an early stage. However, it is important to know that the testability of the implementation, the adherence to a software architecture or approaches such as Test-Driven Development (TDD) are subordinated to the knowledge whether a solution works at all and as desired. Therefore, an explorative and/or experimental prototype should never be put into production. If the prototype is used as it is, this form of shortcut will most likely be punished in the course of the project. In the best case, a mapping to the agreed software architecture must be established, unintended interactions between individual components and features must be eliminated, and numerous tests must be carried out afterwards. In the worst case, the entire functionality must be re-implemented. This means at least twice the work, twice the effort, and a late delivery, even if the prototype is a good template for a reimplementation to look at.

The walking skeleton

A walking skeleton is the simplest implementation of a complete feature. It implements a requirement for a system, with an architecture that has already been thought through and supported. In addition, in contrast to prototype development, the Walking Skeleton places great emphasis on testability, unit tests and modularity from the very beginning. Conceptually, Walking indicates that the implementation is already executable. A prototype, on the other hand, does not necessarily have to be executable; think, for example, of a software user interface or a landing page on the Internet – it is often a question of a look & feel, an impression. The walking is complemented by the skeleton. The skeleton corresponds to a limitation to the basic functionality of the feature or functional area. To stay in the picture: the flesh – i.e. additional features – will be added at a later stage.

In my opinion, a walking skeleton is much more sustainable than the creation of a prototype. However, a walking skeleton also lives with the restriction that it masters exactly one feature. Not two or three, but exactly one. This feature is based – with appropriate implementation – on a reasonable architecture that serves as a framework for future development. The feature does not even have to include the final architecture, but it should already connect the most important architectural components. Architecture and functionality can later be developed in parallel as described in the Twin Peaks model.

The choice of the feature to be implemented is not always easy for organisations and requires some experience. Ideally, you will find a feature that can be implemented as part of the system through all levels of the software architecture. In the literature this breakthrough is also described as vertical prototyping. A similar idea is pursued in the development of the so-called Minimum Viable Products. So the terms used in the context of prototype development are very close together.

Conclusion

Both the prototyping as a process with the prototype as the result and the walking skeleton have their charm. Organisations need to think carefully about their challenges and context in order to decide which approach will work best for them and what they hope for from the result. If they want to better understand requirements or prove a basic functionality, then the development of a prototype makes sense. If you want to use the result further, evolutionary prototyping or walking skeleton makes sense. If I had to choose between these two alternatives, I would opt for the Walking Skeleton. In my experience, the early integrated tests across the layers of the system automatically provide higher quality. However, compared to prototyping, a walking skeleton takes significantly more time and costs; the realised value is of course also greater.

Regardless of my personal preference, both prototyping and walking skeleton offer a good starting point for the dialogue with clients and users. At an early stage, all parties involved can see whether the formulated or not explicitly formulated expectations, the set requirements and the core of the functionality have been met. So in the final analysis, it is not possible to say clearly what is better or worse. Both can work well or less well – but organisations should be aware of the respective alternative.

Notes:

Peter Friedland has published additional articles here in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.