Moldable Development is a way of programming through which we construct custom tools for every software development problem. Glamorous Toolkit is a moldable development environment that can be used to mold custom tools.
Tudor Girba spoke about Moldable Development at QCon Plus November 2021.
Girba stated that Moldable Development addresses the single largest expense in software development today, which is figuring the system out:
Developers alone today typically spend more than half of their time manually reading textual artifacts to decide what to do next. We optimize a large part of this work by creating custom tools that summarize the system. This then leads to decisions made faster and more confidently. It’s like data science, but for software.
For Moldable Development to be economically viable, we need an environment that allows us to mold custom tools inexpensively. Glamorous Toolkit is free and open-source, and it is made to work with many sources of input, as Girba explained:
We use it to reason about code written in various languages, like Java, JavaScript or Ruby. At the same time, it’s also a knowledge management platform in which each page is also a multi-language notebook.
Glamorous Toolkit is also an extensive case study as we are developing it following Moldable Development. For example, in the distribution we have more than a thousand custom little tools that we have constructed to help with the development of the environment itself.
According to Girba, Moldable Development can be a major source of competitive advantage in software development:
I expect that within 5-10 years companies will hire technical storytellers that craft narratives about the inside of their systems. I even expect these narratives to make it into pitches and public marketing materials.
InfoQ interviewed Tudor Girba about Moldable Development.
InfoQ: How does Moldable Development look?
Tudor Girba: Let’s look at an example I gave at QCon Plus 2021. When a feature toggle that is defined in component A is used in component B, you end up with a dependency between those two components. However, this dependency is only visible if you understand the framework the toggle is expressed in. Thus, to draw a diagram about these dependencies automatically, you must create the tool after you know the system’s details.
That’s one example. Most interesting problems in a system relate to contextual details and can benefit from custom tools. Such tools can be queries, visualizations, or even interactive browsers. And they can be about source code, configurations, logs, production events, data in the database … anything that surrounds a system.
InfoQ: Can you give some examples of using Glamorous Toolkit?
Girba: A bit of background first. At feenk, we fund ourselves by solving difficult problems for our customers. We work with two kinds of customers: those who encounter some sort of a crisis with an existing system, and those who seek a competitive advantage.
When we work with teams that have legacy systems that need to change, the challenge is posed by a lack of visibility into the systems. Custom views summarize the system, and once the problem is visible, the solution typically follows quickly.
The same approach can be applied for exploring unknown APIs or sources of data. And, it’s useful for creating new systems, too. For example, by visualizing the objects in the system, we can produce pictures that show the ubiquitous language in a way that non-technical people can understand.
In all these seemingly different areas we use Glamorous Toolkit to create custom environments. And in all these cases, the custom views enable the communication between technical and non-technical people, which then leads to a new feedback loop.
InfoQ: What do you mean by a new feedback loop?
Girba: When tests became code, they introduced a new feedback loop that enabled people to create more complicated systems. When infrastructure became code, a new feedback loop enabled businesses to create new kinds of value that were not possible before. Now, it’s time for tools to become code so that people can accommodate the specific details of each system programmatically. Contextual tools enable people to have deep conversations about their systems which, in turn, improves dramatically how they can steer their systems.
InfoQ: Where and how would you apply Moldable Development? What are the drawbacks?
Girba: We apply it for every single development problem. I know it can sound crazy, but whenever the problem in front of us does not feel comfortable, we stop, we build a custom tool until the problem feels beautiful, and only after that do we go ahead and solve it.
About drawbacks … At this moment in time, I can think of drawbacks of not practising Moldable Development. People might say that constructing tools willy nilly is a waste. Interestingly, we used to have a similar conversation about tests. Of course, it is imaginable to overdo it. That’s why an understanding of the economics of tools is important. What tools to build and when to build them are certainly relevant concerns. But, to understand those tradeoffs, you have to build tools first. There is no way around it.
And, while it is imaginable to overdo it, at this point in time you are likely far from that problem. The thing is that the budget is already allocated. It’s up to you how you spend it: you can either continue reading, or you can build tools that do the reading for you. In other words, if you think building tools is expensive, try not building them.
InfoQ: How should people adopt Moldable Development?
Girba: The simplest step you can take is to just start talking about how you reason about your system. Do that continuously and you will soon start noticing new opportunities around you.
To go deeper, you need to learn about the two roles in Moldable Development. The facilitator knows how to build tools much like how a data scientist does. The stakeholder owns the problem and can act when given the right information. Anyone involved in the system, from the developer to the CEO, can and should be an active stakeholder. Of the two, it’s the stakeholder who’s the most difficult to train, but you should first focus on creating custom tools inexpensively, which basically boils down to learning a piece of technology and a few patterns. Glamorous Toolkit can be a good choice to explore what’s possible.
Once you can create custom tools and can incorporate them into decision making, the real value is extracted when you change the way you work.
InfoQ: What have you learned from using Moldable Development in your daily work?
Girba: More than a decade later, we still notice new surprising things. This only shows that the space is wide and unexplored. I am convinced that we only have the beginning of the conversation. I am also convinced that once we start a global conversation (and start we must) about how we relate to the inside of our systems we will enable a new wave of innovation.