Moldable Development

Moldable development is a way of programming through which you construct custom tools for each problem.

Software is shapeless. We, humans, need a shape to reason about anything. Tools provide the shape of software. By molding our tools to match the context of our systems, every problem in software can be exhibited in a way that a human can relate to and reason about.

Why is it important?

You optimize the single largest expense in software development: figuring the system out.

How does it work?

You build a tool that shows your current problem in a way that makes it easy to grasp. It's like data science, but for software.

What does it entail?

It entails new skills: the facilitator constructs custom tools; the stakeholder knows what to do with them. And, you'll want to change your organization, too.

Principles

Software engineering is primarily a decision making activity.

Software should be explainable when we need it.

Any boundary in software is arbitrary.

There is no single dominant representation of anything in software.

Once a human deems a representation as meaningful, it is the responsibility of the system to carry it forward.

Software architecture is an emergent property.

How to learn moldable development?

Play with Glamorous Toolkit

Moldable development must be experienced. We created Glamorous Toolkit, the moldable development environment, so that you can do just that.

Join the community

Learning is always better together. Join us.

Frequently asked questions

What's the difference between moldable development and literate programming?

They are similar in that they both promote the use of narratives for depicting systems. However, literate programming offers exatly a single narrative, and that narrative is tied to the definition of the code. Through moldable development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code).

Isn't moldable development like model-driven engineering then?

Not quite. It's more similar to model-centric engineering: one system and multiple views on it.

Ok, then isn't it more like visual programming?

No. Typically, visual programming entails a graphical notation with which you create programs. Through moldable development, you construct views orthogonally to how the program was defined. Furthermore, the visuals are not limited to code, but we apply it throughout the whole system, including objects, logs or data.