Mapping Moldable Development

This Wardley Map provides an overview of the key elements of how Moldable Developmentsupports decision making at both technical and business level.

It all starts with a decision about a system which can concern anything, from a narrow technical detail to a broad business concern. Regardless of the scope, every such challenge relates to the system. Decisions need assessment which rely on explorations. Explorations is enabled by conversations, either between humans or between humans and the system, which entail information. Any information can be gathered from a system through a development experience that allow us to synthesize it by using concrete tools out of the system.

The core proposition of Moldable Developmentrevolves around replacing manual views created through manual inspection by views generated automatically, yet are specific to the problem. It's much like data science, only applied to software.

This is important because of two reasons. First, we replace the single largest cost and the greatest source for unnecessary risk. Developers alone spend more than half of their time reading through the system, but your system is too large to be understood manually. As a consequence, pictures produced manually do not reflect the reality of the system. They constitute beliefs rather than accurate engineering tools. And beliefs are not appropriate for any decision making.

Second, automating how information is gathered from the system reduces risks and frees energy that can be used for experimenting and acting. Once you can get answers quickly from a system, a new set of practices is made possible, collectively known as Moldable Development, that supports hypothesis-driven decisions for every single problem related to a software systems.

Creating custom tools can only happen through specific coding. To make this economically viable, we need tools that can be quickly put together in context. A moldable development environment stands in contrast to the institutionalized rigid ones in use today in that custom tools can be created quickly and during development.

"Why do you call existing tools rigid? Don't they have plugin mechanisms?"

Many environments offer some extensibility, but the emphasis is on some . There is a large difference between some problems and all problems. Moldable Development is applicable to every problem, from the narrowest technical issues, to the broadest strategic ones. As long as a decision refers to a system, it needs accurate and timely information about that system. You can get to this accurate information only by embedding the creation of tools in the development flow.

The principle is that whenever a problem is not comfortable enough, you build a tool that makes it comfortable. This can happen multiple times a day even for a single developer. To put it in perspective, in a typical IDE today, you might have dozens of extensions. When practicing Moldable Development, you can easily get to thousands of tools per system.

"Thousands of tools per system?"

Yes. These tools offer contextual views that summarize parts of the system from some perspectives. The availability of contextual views on demand changes decision making fundamentally, and with it, the very act of programming.

"But who creates all those tools?"

Moldable Development involves two distinct roles, each with its own set of skills. Facilitator (in blue on the map) is a technical role that is concerned with the technical part of building tools. But that alone is not enough. Stakeholder (in red) is at least as important. Tools are only meaningful when they relate to a question or hypothesis that is tied to value and when the answers lead to concrete decisions and follow up actions. That's the job of the stakeholder.

Replacing manual inspection through generated custom views introduces a new feedback loop through which people can make decisions based on accurate information about their system. Beside the associated skills and moldable development environment, this feedback loop also enables new processes.