Moldable Development

Moldable Development is a way of programming through custom tools built for each problem.

The problem

When we think of software development, we typically think about the active part. Of constructing. Of building new worlds that never existed. It's an empowering view.

Yet, Developers spend most of their time figuring systems out. They do that because they want to learn enough about the system to make a decision. This is the single largest development expense we have. So, we should optimize software engineering for decision making.

Most of this effort is spent reading. From a decision making perspective, reading is but a means to gather information out of data (everything about your system is data; ok, objects if you are lucky). It also happens to be the most manual way to extract information out of data. And this is where we spend most of our time. The alternative is to treat this as a data problem.

The method

When it comes to reasoning about data, we should always start with a hypothesis, apply an analysis, and interpret the results. If we are confident, we act. If not, we repeat. That's just the scientific method.

However, because software is highly contextual, for a given problem we likely do not have an appropriate tool available.Developers read code because reading can handle any context; the only problem is that it's too slow and innacurate.

That is why it is essential to ask a simple question: "do we have an appropriate tool through which to carry out the analysis?". If we don't have an appropriate tool, we mold one. And we want to do this for every single development problem we encounter. That's the essence of Moldable Development.

The roles

Moldable Development relies on two distinct roles: the Facilitator constructs custom tools; the Stakeholderknows what to do with them. It's really not that different from data science. Except we want them embedded in every team working with a system.

The technology

To make the method effective in practice, we need an environment that makes it possible to create custom experiences through which to interact and reason about systems innexpensively. The Moldable Development Environment

The implications

Custom tools commoditize the process of gathering information about systems. Once this happens, new processes are possible. First, we want to ask many times more questions. Second, we can reimagine how we make decisions concerning a software system as a group.

While the primary focus is on the reading use case, custom experiences apply to how we create software as well.

The act of visualizing a software problem or domain often makes it obvious how the underlying software should change. This introduces a feedback loop that literally can guide the design of a system.

The ultimate goal of Moldable Development is Explainable software.

Moldable Development compresses communication.

When there are no walls between tools, we can explore arbitrary problems in a uniform way. In other words, a single investment in the skills, technology and associated processes can yield many returns.