At Craft Conference 2025, I gave a first public talk in which I introduced Moldable Development through a parallel to Test-driven Development based an extensive case study: Lifeware.

We had the chance to work closely with Lifeware for the past few years and I can say without reservations that Lifeware is an extraordinary organization. Their business is to provide systems for insurance companies. They outcompete their space by a large margin, and the extraordinary part is how they achieve that: by investing in software engineering as a competitive advantage.

They were early adopters of test-driven development (well, of Extreme Programming). And when they did, they went all in. So much so, that in 2002 Kent Beck wrote this about them in "Test-driven Development by Example": "The largest, totally test-driven system I've been involved with is at Lifeware (www.lifeware.ch). After 4 years and 40 person/years, the system contains approximately 250,000 lines of functional code and 250,000 lines of test code in Smalltalk. There are 4,000 tests, executing in under 20 minutes. The full suite is run several times each day. The amount of functionality in the system seems to have no bearing on the effectiveness of TDD."

They were not just practitioners of TDD. They were flagship practitioners. And they did not stop there. In the meantime, their system grew to 35M lines of code containing 150k tests. Yet, they are still able to run those in less than 15 minutes by executing them on a cluster of thousands of processors on AWS. But here is the interesting bit: every developer has access to such a cluster on demand.

And they did not stop there either. Now, they moved to their next large shift: adopting Moldable Development. Even before working with us, they constructed contextual tools for their critical processes. More recently they moved to Glamorous Toolkit as their only development environment, and today, they already have more than 2k contextual tools that complement the tests and help them reason about their system faster.

In the talk I show live examples of how these tools help with investigating test failures, exploring the cluster execution or scripting and performing dedicated refactorings. And all of them are integrated in a single development experience to accommodate seamlessly many workflows.

For example, from the same test run, I showed an investigation of test failures in a way that domain experts could understand, and an investigation of the cluster on which the tests ran in a way that an ops person would relate to.

New optionality at the level of tools only becomes valuable if it is paired with changes in practices. Lifeware has a long history of constructing their own tools and the new environment allowed them to deploy their ability to more ambitious problems. As an example, they had a recent challenge: add translation text for a new language but in only a part of the system.

There were 22k occurrences of strings in the subsystem. But not all of them had to be translated. Only the ones from the administrative interface had to and the others had to remain untouched. To identify which strings are only used in the administrative interface, they instrumented the system and performed a dynamic analysis to see which of the strings were used at runtime in which logical part of the system. Once they had that, they deployed the analysis and ran the whole set of tests in a large cluster against the entire system. It turned out that only about 2k occurrences had to be translated. With the assembled locations that required translations, they could then bundle the requests to a remote service to get the rough translations in place. And finally, the detected places and the new translations were codified in a dedicated rewrite that could be applied on the whole code base.

This kind of problem occurs rarely, but when it does it involves tedious work. Automating this flow required multiple steps, each of which was guided through contextual tools that helped both with constructing the analysis and with understanding the results.

While the overall flow looks like a single tool, it is actually made out of small contextual tools. Piecing them together is based not on a hardcoded flow but on a conversation that people want to have with the system. Each step defines a context, and each context offers associated tools. Choosing them to answer the current question is the job of the human that wants to learn about the system. That's the essence of Moldable Development.

Watch the talk on YouTube.