Getting started with moldable development on existing code
Moldable development with Glamorous Toolkit (GToolkit) can be overwhelming. So many tools, and when you start with existing code, there are so many places to start. Which one do you choose? We often see enthusiastic people try something with GToolkit and then stop when they find out that not everything they need works perfectly yet.
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 development problem can be exhibited in a way that a human can relate to and reason about.
GToolkit offers the building blocks, but these are always changing and improving. Analyzing lots of different languages needs parsing support for them, and all of those languages change. Some not so fast, but others do. Supporting dozens of programming languages means that there is always work to do, and that happens just in time.
Moldable development aims to establish and improve the overall feedback loop. That is what drives the learning. Learning results in explainable systems.
Starting points in existing code
Every context is different, so in moldable development we focus on building custom tools. But for already existing projects there is a lot of shared context that we can leverage. This shared context allows us to already provide worthwhile insights while building up the custom tooling.
This is important because to build and maintain trust with all stakeholders we need to deliver value continuously, and illustrate that we do. Simultaneously we need to tackle the problems we find most difficult.
We need to avoid the pitfall of trying to deliver all the easy things as fast as possible. That would create a huge gap once the easy things are done. Instead we need to deliver just enough of the easy things to maintain and build trust with the stakeholders. And with that create the time to work on the difficult problems.
Development patterns
The book suggests a number of development patterns, starting with a Contextual Playground. Start exploring from a path to the system source code, and collect the files that look interesting.
Solution: Use a contextual playground of the tool to programmatically explore the entities of interest, and prototype new behavior
In addition you also need to use the Tooling Buildup pattern explicitly:
Solution: To start a moldable development activity, first obtain the basic tools you need to start exploring
The other patterns can be introduced gradually. Tooling buildup needs organizational support, as it does not deliver value immediately, and thus requires investment.
The Tooling Buildup Pattern is probably enough for experienced smalltalk developers used to reengineering and migrating legacy code projects, but might not provide enough guide rails for others without this extensive domain specific knowledge. Those also need the time to actually learn how to build these micro tools.
They might benefit from a more guided, painting by numbers approach, with far more explanations.
Paint by numbers
In a consultancy context we need to quickly learn about a project of which we have no prior knowledge. We need to be able to create a map of the landscape, and determine how the statements of the different stakeholders are colored. For two aspects of this we can easily build up generic tooling that might provide us with insights based on data instead of intuition and PowerPoint presentations:
Projects commonly use git for version control, and have some kind of directory and file structure on disk. We can quickly analyze the directory structure and visualize it at file level. We can do the same with the version control commit log to see who has worked when on what. That can give us fast insights in shared knowledge and stability of the development team, and how system responsibilities are distributed.
What do we value?
by doing it and helping others do it.
Through this work we have come to value:
Moldable tools over generic tools
That is, while there is value in the items on
the right, we value the items on the left more.
In paint by numbers we have a clear case, where in order to do what we value most, we need to leverage what we already have. We use generic tools in GToolkit to build context-specific, moldable tools.
