The talk consisted mostly of two stories. Two examples.
I started with a little story inspired by our recent experience of going through the Open edX system.
2/
I started with a little story inspired by our recent experience of going through the Open edX system.
https://twitter.com/feenkcom/status/1425937908981186563?s=20
2/
It went like this. Imagine you have a system written in Python and you want to split it for various reasons.
You'd first look for components that already exist. In this case, the system already seems to have top components available (as documented by top folders).
3/
You'd first look for components that already exist. In this case, the system already seems to have top components available (as documented by top folders).
3/
And then you'd look for dependencies. When we think of dependencies, we typically think of how a system calls or sends a message to another part.
But, there are dependencies that are less obvious.
For example, feature toggles can pose a challenge.
4/
But, there are dependencies that are less obvious.
For example, feature toggles can pose a challenge.
4/
Feature toggles? Yes, feature toggles.
In this particular system, feature toggles are used in many places, as highlighted on this treemap (sorry, @swardley. I know it's not actually a map, but that's what they called this before that distinction was obvious :))
5/
In this particular system, feature toggles are used in many places, as highlighted on this treemap (sorry, @swardley. I know it's not actually a map, but that's what they called this before that distinction was obvious :))
5/
Having many usages of feature toggles is not a problem per se, but it can become relevant if a toggle is defined in one component and used in another, as that would induce a dependency.
That's why it would be ideal to see something like this.
6/
That's why it would be ideal to see something like this.
6/
To draw a graph like this, we'd need to know how toggles are defined and used. But, while a feature toggle is a generic concept, the way to define and use it is framework specific. To make matters more interesting, in our system there are actually 3 different ways to do that.
7/
7/
This means we can only create the tool after we know the specifics. You can't download it. You must build it. And that's the gist of #MoldableDevelopment.
(the alternative is to manually read code, but that's a too expensive data mining tool)
8/
(the alternative is to manually read code, but that's a too expensive data mining tool)
https://twitter.com/girba/status/1352754537522716672?s=20
8/
Back to our case study, the picture is indeed generated through a custom tool. Looking at it, we can already see that there are a significant amount of cross component toggle usages. And that there seem to be cycles, too.
This is already interesting, but ...
9/
This is already interesting, but ...
9/
To bridge the gap to action, we need more details. It would be great to go from the picture to the places in code that induce the dependencies.
Something like this.
10/
Something like this.
10/
This can be achieved through a little model and a few object inspectors with custom views.
The model is not more complicated than the model already used by the runtime of the system, only in this case it's retrieved statically.
11/
The model is not more complicated than the model already used by the runtime of the system, only in this case it's retrieved statically.
11/
This demo is based on #GToolkit, the moldable development environment that we designed specifically so that we can put together interactive custom tools inexpensively.
(It's free and open source, too. Go look at it: gtoolkit.com)
12/
(It's free and open source, too. Go look at it: gtoolkit.com)
12/
The second story is based on a recent issue we actually had with the continuous integration server that builds #GToolkit itself:
github.com/feenkcom/gtool…
Namely, we had an error during the build, and I wanted to highlight the error message from the console.
13/
github.com/feenkcom/gtool…
Namely, we had an error during the build, and I wanted to highlight the error message from the console.
13/
(Incidentally, I showed how I access the Jenkins server right from the knowledge management / multi language system embedded in #GToolkit)
14/
https://twitter.com/feenkcom/status/1405241195887050758?s=20
14/
Ok, long story short, I extended the tool in place to emphasize the error.
15/
15/
Taking a step back, these two case studies look quite distinct. On the one hand, we have something we'd denote as architecture. On the other hand, we have some API calls and monitoring.
Yet, they were served through very similar custom tools and flow ...
16/
Yet, they were served through very similar custom tools and flow ...
16/
That is likely only possible if they are actually not that distinct. That's what we show with #GToolkit. That we can look at the development environment not as a set of features, but as an expressive language that can accommodate many kinds of use cases.
17/
17/
Software development problems are unforeseeable, so answers should not be confined to predefined boxes. We need a #MoldableDevelopment environment.
18/
18/
The talk ends with an overview of #MoldableDevelopment as seen through a #WardleyMap, and with hinting at the far reaching implications towards compressing communication and decision making.
19/
19/
Why is #MoldableDevelopment important?
Read more here:
20/
Read more here:
https://twitter.com/girba/status/1352734434613727232?s=20
20/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
