Discover and read the best of Twitter Threads about #MoldableDevelopment
Most recents (14)
This article 👇 offers an introduction to #MoldableDevelopment.
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.
1/
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.
1/
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/
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/
3/
A case study of #MoldableDevelopment:
A while back we implemented the squarified treemap algorithm in #GToolkit.
The implementation is based on a paper written by Bruls, @mackees and van Wijk in 2000 that describes a heuristics-based algorithm.
1/
A while back we implemented the squarified treemap algorithm in #GToolkit.
The implementation is based on a paper written by Bruls, @mackees and van Wijk in 2000 that describes a heuristics-based algorithm.
1/
The paper describes the algorithm in detail, and most of the explanations are based on visual depictions.
Here is a visualization showing the core iterative steps taken by the algorithm.
2/
Here is a visualization showing the core iterative steps taken by the algorithm.
2/
Of course, the main goal of implementing an algorithm like this is to produce the final picture. Here is how such a result looks like in #GToolkit.
3/
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.
1/
1/
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/
2/
In the not too distant future, we’ll look back to this age and find the present default tools rather quaint.
3/
3/
"Everyone in the team should know the vision. Including the technical people." Sure, says everybody.
"Everyone in the team should know how the implementation. Including the non-technical people." What?!
Yep.
Let me take you on a ride.
1/
"Everyone in the team should know how the implementation. Including the non-technical people." What?!
Yep.
Let me take you on a ride.
1/
Typically, it all starts with a vision.
2/
2/
The interface kind of reflects it.
3/
3/
Last year we shipped a first version of #Lepiter and it felt great to see it flying out the door:
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/
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.
2/
2/
#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/
3/
The recent conversations about #ToolsForThought tend to revolve around note taking. Indeed, a note can be a representation of thought...
2/
2/
But, a tweet can also be a representation of thought.
3/
3/
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.
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/
#GToolkit now features a new component: #Lepiter.
Knowledge Management + Multilanguage Notebooks + Moldable Development.
Let's take a tour.
1/
Knowledge Management + Multilanguage Notebooks + Moldable Development.
Let's take a tour.
1/
Lepiter is made of snippets assembled in pages. Each snippet has its own language and comes with its own editor.
In its simplest form, it's a Markdown note taker with live markup that appears on demand and expandable links.
2/
In its simplest form, it's a Markdown note taker with live markup that appears on demand and expandable links.
2/
When combined with a table of contents, pages can form a book.
3/
3/
#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/
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.
2/
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.
3/
Still, it is relevant because it tackles the single largest expense in software development: figuring the system out.
3/
A while back, I asked “what is architecture?” and I got many responses within just one day. Some serious, some more (bitter-sweet) joking. We can identify some cluster of responses, but even so, there are certainly a dozen distinct perspectives.
1/
1/
That there are many perspectives is not a surprise given that the literature is full with competing definitions. For example, it's not atypical for architecture books to say something like: “there exists many definitions, so here is ours”.
2/
2/
The search for the perfect definition of architecture captured the imagination of several generations by now, yet it still seems to remain elusive. But, what if it’s Ok to have many of them?
3/
3/
The monolith vs microservices debate…
By now there is plenty of evidence that both architectures can lead to a “mess”. This only shows that we should not look at these as mechanisms for controlling the said mess” in the first place.
The answer lies somewhere else.
1/
By now there is plenty of evidence that both architectures can lead to a “mess”. This only shows that we should not look at these as mechanisms for controlling the said mess” in the first place.
The answer lies somewhere else.
1/
“It’s the people!”
Well, as long as it’s people building the system, of course it’s the people. But, saying that does not get us closer to figuring a way forward though.
2/
Well, as long as it’s people building the system, of course it’s the people. But, saying that does not get us closer to figuring a way forward though.
2/
Now, what exactly does “mess” mean? The famous spaghetti code?
Mess tends to assume that there is a clean way. And by clean, people typically mean easy to understand and change.
3/
Mess tends to assume that there is a clean way. And by clean, people typically mean easy to understand and change.
3/
“Developers spend most of their time figuring the system out."
Let’s dissect this a little.
🧵
1/
Let’s dissect this a little.
🧵
1/
The oldest reference on the topic I know of dates back to 1979:
Zelkowitz, Shaw, and Gannon. Principles of software engineering and design. Prentice-Hall Englewood Cliffs, 1979.
2/
Zelkowitz, Shaw, and Gannon. Principles of software engineering and design. Prentice-Hall Englewood Cliffs, 1979.
2/
It said that most of the development time was spent on maintenance (67% in the book).
Granted, the book does not specify how the figure was obtained. Still, it was deemed an important enough problem to attract significant research attention since then.
3/
Granted, the book does not specify how the figure was obtained. Still, it was deemed an important enough problem to attract significant research attention since then.
3/
SegĂşn diferentes estudios los desarrolladores dedicamos al menos un 50% de nuestro tiempo a "leer cĂłdigo".
Sin embargo, cĂłmo leemos cĂłdigo es un tema muy poco tratado. La mayor parte de confs, libros, posts y conversaciones se centran en la construcciĂłn y no en la comprensiĂłn.
Sin embargo, cĂłmo leemos cĂłdigo es un tema muy poco tratado. La mayor parte de confs, libros, posts y conversaciones se centran en la construcciĂłn y no en la comprensiĂłn.
Siendo la comprensión del código la actividad más cara en el desarrollo de software, es sorprendente la poca atención que recibe.
Ni siquiera desde #SoftwareEconomics veo suficiente atención sobre estos temas. Quizá @artolamola tenga alguna explicación o refs que no conozco.
Ni siquiera desde #SoftwareEconomics veo suficiente atención sobre estos temas. Quizá @artolamola tenga alguna explicación o refs que no conozco.
Si leemos el cĂłdigo es como un medio para ayudarnos en la toma de decisiones respecto de sistemas de software.
Creo que tiene sentido que empecemos a entender el desarrollo de software más como una actividad de toma de decisiones que de construcción.
Creo que tiene sentido que empecemos a entender el desarrollo de software más como una actividad de toma de decisiones que de construcción.
The governor of New Jersey called explicitly for COBOL programmers to help with the development of the unemployment system:
This is how the software environmentalism crisis looks like. An explanatory thread. 1/
This is how the software environmentalism crisis looks like. An explanatory thread. 1/
In the software development industry, we focus exclusively on building systems. The conversations are dominated by new languages, new frameworks, new deployment options. And the body of software grows exponentially. At the same time, we are unable to remove old systems. 2/
From this perspective, our software industry behave not unlike the plastic industry: we focus on building without any regards to recyclability. That is not sustainable. And, given the breadth of software’s reach, it is not responsible either. 3/
