I had a chat with Simon Wardley about Moldable Development.

The whole conversation revolved around a Wardley Map which was backed by live stories delivered in Glamorous Toolkit.

Let's take the story step by step.

Moldable Development is a way of programming through custom tools built for each problem. It's not atypical to have thousands of tools ... per system.

Per system?!!

Yes. I know it sounds crazy. And Simon asked the same thing.

The goal is to make better decisions. Decisions are based on investigations. Investigations require explorations which need conversations (between people and systems). These need a means to know about the system. System awareness needs analysis which relies on the development experience.

Today, the process is very much gut feel driven based on ad-hoc explorations. Conversations are data centric in that they contain data. But the data is often based on beliefs about the system. It's all due to how we gather information: manually using rigid monolithic tools.

So, how else can it look like then?

Let's look at a story of a migration of a core database. It was deemed a very important strategic project, but 6 months into it, people had a problem: they realized they also have to change the systems. Which systems? They did not know.

So, we looked at the problem (that's what we do at feenk).

We asked then if they have the sources of these systems. They did not have them. They did not even know where the sources were. They only had some sources for a new project in which they started to isolate the DB calls through services.

Eventually, we got other data pieces. Logs of SQL execution from the database. Logs from the newly created services. Sources from services. Mappings between app names and IPs (that was another thing we had to help with). And the DB schemas.

Obviously, we needed a tool to make sense of this space. But where can we get a tool that can analyze exactly these sources of information with exactly these semantics? No such tool exists out of the box.

So, we built one. That's the essence of Moldable Development.

We got a visualization of the space: black dots are systems, red squares are tables and blue dots are the new services. Their original assumption was to delegate the work to each system's team. But here we saw clusters of systems. So, more coordination was needed.

Now, this is just one picture. But the key to enabling the investigation was the exploratory environment that could go to the line of code (when it was available).

Environments like this are not only useful in the early decision making stages, but also during migrations.

This brings us back to our map.

Once we can generate dedicated views, a whole new set of practices are enabled. The process is guided by hypotheses. Exploration can be systematic. Conversations are model centric and our awareness of the system is always inspectable.

Now, this idea not only works on large problems. It works on small problems, too.

For example, we had a bug in our editor that we could not figure out for a long time. We could solve it only after we built a Rust inspector to see the problem.

These process works with every problem at any level of abstract that we encountered over the past decade or so. It's systematic.

These custom tools compress the system for our interest and this then changes the nature of the conversations we have about our systems. For example, here we have a documentation showing the rules of a board game. We see the board and a possible move. Nothing special.

But where does this picture come from?

You guessed it. It comes from the system itself!

There is an example code (like a test that returns an object) that produces a move object which is then visualized with a custom view.

The documentation is merely a side effect. And it's always tested.

These custom tools also allow us to bridge gaps in our system analyses.

For example, let's consider browsing the API of a Ruby on Rails system. We could just browse the routes.rb. But if we are interested in the implementation, we have to manually look for the controller code.

Instead, what if we do not start from the source code at all?!

A list of end points is more interesting. And when we look at an end point why not see both the route definition and the implementation at a glance. No extra work.

Moldable Development requires a completely different development experience. One that optimizes for reading first and foremost instead of writing.

Generic tools are appealing because they are widely applicable. But they don't tell us interesting things.

Take a look at these objects. In a generic inspector all objects look identical.

Dedicated views make them suitable for humans. Same objects. Different shapes.

If we control the experience through which we perceive our systems, we can dramatically influence how we make decisions about our systems.

Ok, this sounds interesting ... in theory! But thousands of tools?!

Good question!

Yes, thousands of tools per system does sound crazy. And you are in good company, too, because that's what Simon asked as well. And he had me show him how we can build tools in minutes while we reason about a problem. So, I did.

And it might already be impressive enough, but what was less visible is that if we make the environment be made of visual and interactive operators, we can combine those custom tools in a myriad of ways to handle all sorts of narratives dynamically and at almost zero cost.

Another thing to notice when looking at the map is that business ends up relying on the development experience. How is that?

Well, the I in IDE stands for integrated. A true integration includes all stakeholders. Including business and even users.

If you made it this far you must be interested enough. Take a look at the video to hear more juicy stories and see live examples.

Then go to gtoolkit.com to play with custom tools yourself. Glamorous Toolkit is not only an environment to learn Moldable Development with, it is an environment to learn from. It is the largest case study of Moldable Development to date. Out of the box there are thousands of extensions that we used to guide the development of the environment itself.

And then join us on Discord to learn together with us. It's a new world to discover.