Thread by @girba

#MoldableDevelopment is a way of programming through which you construct custom tools for each problem.

What does that mean exactly?
Where does it come from?
Why is it relevant?

Read on.

1/

The original idea of #MoldableDevelopment came from the work on Humane Assessment through which I argued that we need custom tools to reason about software systems effectively.

https://twitter.com/girba/status/1311723950523781120?s=20

2/

The idea of custom tools is a significant departure from the typical software engineering canons which often argue the opposite.

Still, it is relevant because it tackles the single largest expense in software development: figuring the system out.

https://twitter.com/girba/status/1352734434613727232?s=20

3/

At first, we applied this to inspecting systems. This alone had implications for the development process. For example, for steering agile architecture.

https://twitter.com/girba/status/1352255981464522756?s=20

3/

It was only a few years later that @Chis_Andrei and colleagues showed that we can apply the same principles to the whole development lifecycle:

(a thesis worth going through)
scg.unibe.ch/archive/phd/ch…

4/

Specifically, @Chis_Andrei's thesis says that:

"... software development tools need to support inexpensive creation of domain-specific extensions, and automatically select extensions based on the domain model and the developer’s interaction with the domain model."

5/

Note how context is defined both in terms of the domain and of the developer's interaction with that domain. In particular, the latter emphasizes that the tool must match the individual *after* the problem is known.

6/

Because software is highly contextual, we cannot predict the specific problems people will have. We can predict classes of problems, but not specific problems. That's why ready made tools are never enough. We need to construct tools after we know the problem.

7/

What's a custom tool?

A query can be a custom tool.
A visualization can be a custom tool.
A browser can be a custom tool.
A constraint can be a custom tool.

The key is only that it's made to match the question, and not that the question is made to match the tool.

8/

Here is an example:

https://twitter.com/feenkcom/status/1350878145575071745?s=20

9/

And another one:

https://twitter.com/feenkcom/status/1273174599996518400?s=20

10/

And another one:

https://twitter.com/feenkcom/status/1293203919309615105?s=20

11/

For custom tools to be practical, they need to be inexpensive to create. This, in turn, requires an appropriate environment. A moldable environment.

#gtoolkit shows how this can work in practice.

gtoolkit.com

12/

First, we applied it to inspecting. Then to debugging. Then to search. Then to documentation. Then to editing.

And now, we apply it to adjacent domains.
(I am so looking forward to talk about this one)

13/

(A note: What you see at gtoolkit.com is the second generation of the project.

Also, we actually left the code editor to the very end because we knew we wanted an experience that does not start and is not centered around an editor. More on that another time.)

14/

#gtoolkit is also the first significant system built through #MoldableDevelopment. It is not only the medium to experience moldable development, it is an extensive case study, too. Learning #gtoolkit is essentially indistinguishable from learning #MoldableDevelopment.

15/

We also applied and validated #MoldableDevelopment in industry for more than a decade.

Before @feenkcom, I even took a job to lead the development on the scariest legacy system I could find around just to live with the consequences of my decisions. 3.5 years. It worked.

16/

At @feenkcom we got the chance to work with many challenging situations and systems. Some systems were old. Some systems were brand new. Some were large. Some were small. All required explaining. And all were critical.

https://twitter.com/feenkcom/status/1379468155349766145?s=20

17/

An example of a legacy challenge.

A large central database needed to be migrated to a new structure. The challenge: what applications need changing and how? How did we answer? We built a custom tool with which we navigate and query the landscape.

18/

Another example of a legacy challenge: Reverse engineer and port a core part of a critical system.

We were given 1 year. We did it in 1 month.
In the video here @thorgch from Lam Research describes the experience of working with us.



19/

And here is an example for a new system. In this case, we tell a story about privacy by showing the inside of the system. This serves both as a vehicle for dsicovering the domain and as a means to replace a business presentation deck.



20/

These are rather diverse situations. Yet, in all cases, we used exactly the same tools and techniques. Why? Because we are stubborn. And because this is the only way to validate that #MoldableDevelopment works. And it just works.

21/

All this work is tightly related to #gtoolkit. It is the vehicle with which we do our work and it is what we use to teach. We built it because only talking about these ideas was not enough. And because it's just pure fun.

22/

It's also worth noting that along the way we built a few other adjacent things.

For example, we replaced tests with examples and created live documentation.

https://twitter.com/feenkcom/status/1096093636700356608?s=20

23/

We even built our own graphical stack just to be able to express new interactions.

https://twitter.com/feenkcom/status/1225901550083510272?s=20

24/

All this to say that #gtoolkit is interesting for multiple reasons. Still, the most interesting is how it documents the approach with which it was built. If you let it, it can teach you.

https://twitter.com/feenkcom/status/1362471657152077831?s=20

25/

An important lesson we learnt while building #gtoolkit is that any boundary in software is arbitrary. The corrolary of it is that once we can make a level explainable (e.g., user interface), we can make any level explainable.

https://twitter.com/girba/status/1291837537535897602?s=20

26/

#MoldableDevelopment works at any level of abstraction and for any single development problem. It's for large problems. It's for small problems. And, it just works.

27/

Ah, who is #MoldableDevelopment for?

First and foremost, for developers. Oh, are you worried you do not have time to learn it? Legitimate. Then again, think of all the time you spend reading. And then think how that makes you feel. What if you could smile while debugging?

28/

But, it's also for business people and managers. Business people and managers?

#MoldableDevelopment adds a new feedback loop. You should care about it because the previous feedback loops changed the business. This one will do the same.

https://twitter.com/girba/status/1286779589709234182?s=20

29/

Want to learn more?

Play with gtoolkit.com.

Join the conversation here:
discord.gg/FTJr9gP

Or just ping us.

30/