For Christmas my in-laws gifted me a cuckoo clock from the Black Forest in Germany. It is an amazing piece of engineering and art. But I wanted to know more about how they are made and especially how they are tested.
To my surprise, the software development process has much in common with the making of cuckoo clocks.
First, much like recent software development, each logical component in a cuckoo clock is tested by itself. For instance, the “movement”, which is the name given to the clock mechanism located within, is tested much like unit-testing components or functions in software systems.
Then, as pieces are integrated together, they are tested much like software, where integration testing aims to find faults in the interface and communication between components.
For instance, if a wire is too long when the movement is introduced into its enclosure or the bird does not fit within the wood piece, the error is fixed and integration is attempted once more.
Finally, when all the components are assembled to form the cuckoo clock itself, the entire piece is not only inspected, but also thoroughly tested by running it for two days straight to ensure proper functionality. This is the so-called system, end-to-end, or even acceptance testing approach for software, where the entire system is exercised to verify that it meets the required use cases.
Additionally and much like in software, the cuckoo clock is system/acceptance tested to assess the risk of shipping the clock as is, or if it needs re-work.
Behind the Scenes
One aspect of creating cuckoo clocks that we do not see, however, is the modeling and design aspect.
You see, even before the components are assembled together, and even before unit testing begins, there is a certain degree of trust placed in the sub-components.
For example, the people assembling the clocks trust that the gears are the right size, with the right number of teeth. Further, they also trust that the wood parts adhere to certain dimensions and when they assemble them together, those wood parts will fit.
This is the aspect of development that is also important, yet often overlooked by many testers. The design and modelling of software systems can be considered similar to the design and modelling of the many components that form the clock, such as the gears or the wood parts, for instance. For these kinds of clocks, computer-aided software is used to some degree.
Then when the parts are ready to be produced, they are created by computer-aided machines due to the high amount of precision required for those parts.
In other words, well-tested systems are not well-tested simply because a human interacts and tinkers with them. Well-tested systems are designed to be tested well from the ground up.
See how its done
Here are two videos that show the amazing workmanship for these pieces of art. Enjoy!
Wait, this is not Agile!
And you would be correct.
Waterfall-like production methods work best for certain products (like cuckoo clocks) because producing them has been done many times before, with gradual (yet important) innovations and improvements as time has passed.
In contrast, agile methods fit certain (but not all) software projects better because agile maximizes learning, reduces uncertainty by decreasing the fail-fix timeline, and relies on continuous integration to ship partially completed subsets of the product.
In terms of agile, this is the flexibility of software, and is just something that cannot be done with cuckoo clocks that need to arrive fully-constructed and complete to the customer’s door. On the other hand, there are software projects that are indeed not suited to agile methods, and this is a very interesting and important consideration.
With respect to software testing (and contrary to what several popular consultants want you to believe), true context-driven testers know that exploratory testing does not fit all software projects, so different approaches are required to maximize the effectiveness of our testing.
All in all, cuckoo clocks are fascinating pieces of work, and their survival over the centuries (as well as their continued distribution throughout the world) attests to their high-quality development and testing… even if (or perhaps because they are ) done with a waterfall approach.