Moldable Development
Through moldable development, we approach every development problem as a data science problem and we build custom tools to make sense of it. This change of perspective affects the entire development.
The code reading problem
Figuring your system out occupies most of the development effort. Developers alone spend more than half of their time doing just that. This effort is most often spent through code reading. The reason developers read code is that the code holds the current information that is required to inform what to do next. This is decision making and it accounts for the single largest expense in software development.
Molding tools
However, everything about your system, including code, is data. Reading is the most manual way to extract information out of a data. Data is best dealt with through custom tools that are specific to the question we want to answer with data. Through moldable development, developers construct custom tools for every problem. It's like data science for software development.
To make this approach practical, the cost of creating new tools must be close to zero. For this you need a new kind of a platform: a moldable environmnet. Glamorous Toolkit is such an environment constructed specifically to enable moldable development.
Beyond tools
For moldable development to be practical, we need to be able to create custom tools inexpensively. Glamorous Toolkit offers a concrete platform that shows how this is possible. Developers can create custom tools for every development problem to learn from the system and inform the decision of what to do next. Essentially, we replace the manual code reading with custom automation thereby decreaing the cost significantly.
While tools are essential, they are not enough. Whenever we replace manual work with automation, we extract the real value when we adapt our skills and affect our processes.
Roles: the facilitator and the stakeholder
There are two distinct roles involved:
- the stakeholder owns the problem and knows how to interpret the results.
- the facilitator molds the tools and helps the stakeholder to make the decision and act.
These are roles. They can be fullfilled by the same person, but it is often practical to have two separate persons involved for an individual problem. Of these, the facilitator is the easiest to train as it's mostly about learning a new technology. The stakeholder role, on the other hand, is tricker as it implies a change of habbit.
Processes
The development process must be affected as well to exploit the new abilities. When it comes to technical assessment, we can split the space along two dimensions:
- Does the problem appear once, or is it of continuous concern?
- Is the problem concrete (can you say when it's finished?), or is it described broadly?
The daily assessment process helps us address problems of continuous concern. Agile architecture can be steered effectively through it.
A narrowly defined technical problem, like a bug or an architectural violation, benefits from a spike. A broad problem does include multiple spikes, but it must also deal with various other factors, such as negotiating between different business stakholders.
Examples
Evaluating @Deprecated classes in Java systems with Glamorous Toolkit