XDoc

Moldable development at IDE Summit 2020

I had the pleasure of participating and presenting at IDE Summit 2020, an online event focused on ... you guessed it, IDEs . I talked about moldable development and how we should not read code. It appeared to be at least intriguing, if not outright contrarian.

The talk was accompanied by a slideshow delivered in Glamorous Toolkit. "Inception!" said someone. Yep, but it is one that you actually really want. I mean, you would not want to talk about your IDE somewhere else, would you? Why not? Because every time you leave the IDE to do anything about your system, the "I" has failed.

Here is the story I told.

Moldable development is a novel practice
Moldable development is a novel practice

While it is the active part of creating systems that captures the conversation, developers spend most of their time reading code. They do that with the specific purpose of understanding enough to make decisions. Yet, we never really talk about how this time is being spent. This means that we spend the largest chunk of our budget on one single activity about which nobody talks. If it's not a subject of conversation, it is not explicit. If it is not explicit, it has never been optimized. We need to optimize for that, because reading is the most manual way to extract information out of systems.

file://pictures/idesummit2020 - 4.jpg

This requires a novel concept of the development environment starting with the smallest unit: the inspector. Consider these six objects represented generically. This representation is applicable to all possible objects. This is great as we can reuse the effort that went into it. Yet, that is exactly why, the representation is not interesting.

Six objects represented generically
Six objects represented generically

If we change the views, we change our perception dramatically: it is both more productive and more pleasant.

Six objects visualized differently
Six objects visualized differently

We learn from this that there is no single dominant perspective on any aspect of software. The environment must embrace this as a core property. It needs to become moldable.

There is no single dominant perspective on any aspect of software
There is no single dominant perspective on any aspect of software

Enter Glamorous Toolkit. The moldable development environment.

Glamorous Toolkit is the moldable development environment
Glamorous Toolkit is the moldable development environment

In Glamorous Toolkit, the inspector asks every object about how it wants to be displayed. A seemingly small change with far reaching implications.

Inspectors in Glamorous Toolkit
Inspectors in Glamorous Toolkit

Let's take an example: A playground with a query over the code to reveal all the methods that extend the inspector. Inspecting the result shows a filter object that knows how to present itself. How? Through a list of editors. We transformed the playground into a code query tool, and we are writing code in the inspector. So, how would you call this tool?

Querying from the playground. Writing code in the inspector
Querying from the playground. Writing code in the inspector

Any boundary in software is arbitrary. All silos induced by tools are arbitrary. Any interface at any level is just that: arbitrary. This means that whatever principle you apply at one level you should be able to apply it to all layers. There should be no black box.

Any boundary in software is arbitrary
Any boundary in software is arbitrary

Once the environment embraces that, the possibilities are boundless. Here we visualize the dependencies between the components of a React Native application and see the code for each of these.

Browsing a React Native system
Browsing a React Native system

And of course, the principles do not stop with an inspector. Here is an example of a live explanation in which the links on the left connect to the code on the right.

Explanation of a React component
Explanation of a React component

We can do all this because the environment is a language made out of visual and interactive operators that can be combined in many ways inexpensively. Through these the human can mold to the environment to the context rather than being forced to adapt to a rigid representation.

The environment is a language
The environment is a language

One more example: code comments are live documents that can be navigated using the same mechanism as in the inspector. By doing that, we transform the whole system into a browsable wiki that can be understood by non-technical people, too.

Live code comments transform the system into a browsable wiki
Live code comments transform the system into a browsable wiki

Glamorous Toolkit ships with more than 1k extensions just for the inspector. More than 1k plugins working in parallel to depict the multiple facets of our system. The visualization below shows in blue the classes that have at least one such extension from the overall system. The classes in green are examples, but let's leave them for another summit.

The bottom line? Moldability is a pervasive need.

Moldability is a pervasive need
Moldability is a pervasive need

That's it. Oh, by the way, Glamorous Toolkit is built by feenk. We build these tools because we use them every day to solve problems others deem difficult or impossible.

feenk.com
feenk.com

Load the slideshow in Glamorous Toolkit

In a Glamorous Toolkit, load the code and open the slideshow:

Metacello new
   baseline: 'FeenkMoldableDevelopmentIDESummit2020';
   repository: 'github://feenkcom/feenk-stories:main/src';
   load.

FkMoldableDevelopmentIDESummit2020 open