It's written for a first time reader. It's not quite short, but it's not that long either (~4000 words). It has concrete examples, but also a little broader theory.
It starts from the reading problem: reading accounts for the single largest expense in software development today, but it's just a strategy to gather information from the system. We can automate much of it, but we should do it through custom tools.
2/
To give a hint as to why this is relevant, I describe of an experiment in which we gave student teams the same requirements and a constrained tech. They produced very different structures which suggests that a system's inside emerges over time and that we need to react to it.
3/
I then describe a public exercise in which we explored the use of system properties and feature toggles in Open edX. Automating the detections necessarily required a custom solution that matched the internal framework used for defining these properties.
4/
Even more interesting was how once we had an overview of the definitions and usages of properties, we could also identify dependencies that would otherwise remain hidden.
5/
You can learn more details about this exercise here:
This is just an example, but it shows what building custom tools could mean. For this proposition to be practical, the construction of custom tools must be inexpensive. We develop #GToolkit to show how #MoldableDevelopment can work in practice.
#GToolkit is not only an enabling technology, it is also an elaborate case study of #MoldableDevelopment. To exemplify this idea, I show a couple of scenarios in which we use the environment to document and reason about the environment itself.
8/
The technology is important, but the key resides in the method of working. This implies new skills (and roles) and new opportunities for working as a team.
9/
By decreasing the cost of insights about the system, #MoldableDevelopment introduces a new feedback loop that has far reaching consequences also for the business.
10/
Working with @BenLinders on this article was just extraordinary.
I hit a writer's block at the beginning of the year, but Ben kept pushing diligently for 8 months! Along the way he helped me refine the article to make it more digestible for first readers.
Thank you Ben!
11/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@swardley I find that the most exciting part, which might also be the most difficult to explain, is that conclusions seem to emerge before people agreeing with each other, or even before any of the participants having the conclusion formed a priori.
I think that's extraordinary.
2/
@swardley Perhaps an example might shed some light.
In one of the groups, we build 3 maps. Each of them started with a certain assumption, and in each case mapping further sentences eventually turned the assumption upside down. Literally. In all three cases. With the same people.
3/
A beautiful example of #MoldableDevelopment. The view itself is not the most interesting part. The fact that you can write it with a screen of code is. That code is the legend of the tool.
While the tool is generic, we can easily imagine customizing it for specific contexts. For example, highlight specific files that are important for a specific investigation, like those from a special folder. When every view is an extension, you enable a rich experience.
2/
In the not too distant future, we’ll look back to this age and find the present default tools rather quaint.
Lepiter is the latest significant step in our journey to making systems explainable. Here is a behind the scene peak of how we got here.
1/
Our guiding north star @feenkcom is making the inside of systems explainable. We spent a great deal of energy rethinking how we can figure systems out, and this led to #MoldableDevelopment and #GToolkit.
#GToolkit proposes a new development experience. We see the environment as a language made out of visual and interactive operators that can be combined in many ways while working with the environment.
3/