**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. page 
Yet, when we look at what developers do, they actually spend most of their time figuring the system out. page
This currently happens implicitly. This is the single largest development expense we have. We have to make it explicit because that's the only way to optimize it. So, let's start that conversation. See gtoolkit
Most of the figuring the system out time is spent reading. The reason people read code is to understand enough so that they figure out what to do next. That's Decision Making.
From this 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.
**Therefore:**
The alternative is to treat this as a data problem.
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.
Ok. That's not new. It's just the scientific method.
However, because software is highly contextual, for a given problem we likely do not have an appropriate tool available. This is the main reason why developer read code: reading can handle any context; the only problem is that it's too slow and innacurate.
That is why it is essential to ask this simple question: "do we have an appropriate tool?". And if we don't have an appropriate tool? We mold one. And we want to do this for every single development problem we have. That's the essence of Moldable Development.
**Diagram:**
Moldable Development boils down to a set of learnable patterns. book
# Related Patterns
**Notes:** **Work to be done next:**
~
Write a couple of sentences that describe the solution captured by this pattern. Drag flags to make connections.
DOT FROM two-level-diagram