Start with a Walking Skeleton
Clint Shank
One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a walking skeleton. A walking skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components. Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.
Once the skeleton is in place, it’s time to put it on a workout program. Bulk it up with full body workouts. This means implement incrementally, adding end-to-end functionality. The goal is to keep the system running, all the while growing the skeleton.
Making changes to an architecture is harder and more expensive the longer it has been around and the bigger it gets. We want to find mistakes early. This approach gives us a short feedback cycle from which we can more quickly adapt and work iteratively as necessary to meet the business’s prioritized list of runtime-discernible quality attributes. Assumptions about the architecture are validated earlier. The architecture is more easily evolved because problems are found at an earlier stage when less has been invested in its implementation.
The bigger the system, the more important it is to use this strategy. In a small application, one developer can implement a feature from top to bottom relatively quickly, but this becomes impractical with larger systems. It is quite common to have multiple developers on a single team or even on multiple, possibly distributed, teams involved in implementing end-to-end. Consequently, more coordination is necessary. And naturally, developers implement at a different pace. Some developers can accomplish a lot and in little time while others can spend a lot of time implementing very little. More difficult and time consuming efforts should be done earlier in the project.
Start with a walking skeleton, keep it running, and grow it incrementally.
Clint Shank
One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a walking skeleton. A walking skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components. Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.
Once the skeleton is in place, it’s time to put it on a workout program. Bulk it up with full body workouts. This means implement incrementally, adding end-to-end functionality. The goal is to keep the system running, all the while growing the skeleton.
Making changes to an architecture is harder and more expensive the longer it has been around and the bigger it gets. We want to find mistakes early. This approach gives us a short feedback cycle from which we can more quickly adapt and work iteratively as necessary to meet the business’s prioritized list of runtime-discernible quality attributes. Assumptions about the architecture are validated earlier. The architecture is more easily evolved because problems are found at an earlier stage when less has been invested in its implementation.
The bigger the system, the more important it is to use this strategy. In a small application, one developer can implement a feature from top to bottom relatively quickly, but this becomes impractical with larger systems. It is quite common to have multiple developers on a single team or even on multiple, possibly distributed, teams involved in implementing end-to-end. Consequently, more coordination is necessary. And naturally, developers implement at a different pace. Some developers can accomplish a lot and in little time while others can spend a lot of time implementing very little. More difficult and time consuming efforts should be done earlier in the project.
Start with a walking skeleton, keep it running, and grow it incrementally.