Mapping Moldable Development
It all starts with some challenge which can concern anything, from a narrow technical detail to a broad business concern. Regardless of the scope, every such challenge relates to a specific problem and requires a decision.
Each decision requires information. Today, much information is gathered through manual inspection and put together manually, too. This does not scale as systems are too large and change too quickly to be grasped manually. In fact, Developers spend most of their time figuring systems out.
We want to optimize this activity by relying on generated views instead. And because systems are highly contextual, we also want these views to be contextual. This 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 typical 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.