Transcript
Girba: I would like to talk about moldable development. Moldable development is a way of programming through which we construct custom tools for every single development problem we have. Let me show you how this one works in a couple of examples. For the first example, imagine you have a server side written in Python, and you want to split it for various reasons. The first thing you would do is you would say, are there any top level components that are obvious? In this case, it turns out that there are. Then the next thing you'll do is you'll look for dependencies. Now, when we think about dependencies, you typically look for code dependencies, like some part of the system is calling or sending a message to some other part of the system. In this specific project, there was another challenge that was posed by feature toggles. Why is it a challenge? First, it should be said that there are quite a number of usages of feature toggles. Here we are highlighting all the places in the system that are relying in one way or another on feature toggles. From another perspective, it can be challenging for splitting, because if a feature toggle is defined in a component, and used in another component, that induces actually a dependency between those components. It's a dependency that is more hidden. It's not obvious. It's not easy to see. What you'd like is you'd like to see, are there any places, or what are the places in the system that are defining feature toggles in one way, and then using that same feature toggle in some other component through the system? Are there many of those kinds of cases?
It would be an interesting view to have. It will be a view like this, where we'll see some components, and a line is being drawn when a toggle is being used in one place, and defined in some other place. That's exactly what we're seeing here. There are two ways at least in which we could put this view together. One would be to go and read the code and manually put together this information. Another one would be to actually build a tool that draws this for us. In this case, this is the latter case, of course. The question is, how do we build a tool like that? The thing about feature toggles is that there is not a generic way of defining feature toggles. They depend on the framework or the mechanisms that are specific to the systems. In this case, actually, in this system, there are three different variations of defining a feature toggle. All of those would have to be taken into account when drawing these lines. It's fair to say that this specific configuration is reasonably unique for this system. Which also means that if an automatic tool would be built, or show something like this, it would also have to be unique for this system. That's exactly what this tool here is. All of a sudden, we could see here, there are cycles. There's not an insignificant amount of toggles being shared across boundaries.
Of course, this already can lead to interesting conversations, both on the technical side and maybe even on the business side. If we want to bridge this knowledge to some action, like correcting the system, we would need to go and dive into it. If I would click on this line, I would like to see all the places that are inducing those kinds of dependencies. Here, for example, I can see this is in toggle used, that's an object. I'm basically representing the knowledge that I have about how toggles are being defined and used, and then building a little model. That model is made out of objects. The objects know how to draw themselves. For example, they can show where in the source code they are being used. This is one feature toggle and here's another one defined in a different way, in this case, via a string.
When we are seeing a browser like this, there is a value that is added by the tool, because not only does it inform that there is a problem, but it also provides the bridge that is needed to say, what would I need to do to correct it? This is achieved by putting together a couple of views and a few objects, once I know what the model underneath the system is. Here, for example, we have a little browser where I have the interesting toggles on the left-hand side, and the view of the source code on the right-hand side. That alone for this specific problem is a custom made experience that matches. This experience doesn't necessarily have to match for any other problem. For this specific problem, it's an interesting perspective. It's not an expensive or elaborate tool, but it's probably good enough for the purpose of this exploration.
Glamorous Toolkit
In order to put this together, we need to have an environment that allows us to quickly put those kinds of things together. That's what Glamorous Toolkit is. Glamorous Toolkit is the environment that you're seeing live here. It's something we call a moldable development environment. We designed it specifically for the purpose of empowering developers to create their own tools for every one of their problems. This is also an open source project. The primary target of it is to educate as to what moldable development is and what impact it could have.
The second problem I want to describe is actually a problem that we just encountered during the development of Glamorous Toolkit itself. Here we're seeing another inspector, in this case, showing us the overview of a Jenkins build server. In this case, there's nothing to do with static analysis, this is an API call. We get back an object or get back a response that we captured as an object, and it knows how to show itself. For example, here it shows me the list of runs. This inspector is part of a notebook here that is also a knowledge management system. What we learn here is, we can see that we haven't done a great job recently at keeping the build green. More intriguing is this one here, which is, there was some error during the build. I would like to take a closer look at that.
When I look at that, I can see I have a pipeline run with different nodes here. I can see there are two failures here. Maybe a different view would be this one that actually shows the graph layout of the pipeline. Now I can see, probably I should focus on this one. As I click on that, there was another call to the API, and now I get the details about that pipeline run which has multiple of these steps. Every one of those steps corresponds to the commands that we give in Jenkins. Then, for every one of those commands, we get a console over here. We can see, splitting the large console onto small pieces is already an interesting experience. More interesting here is actually that there's this interesting custom made syntax highlighting. In this case, we have an exit code 1. That's obviously some error. We wanted to have it highlighted. The problem here is that we still don't know exactly what the error is.
What I will do now is I will quickly browse this code. When I browse through code, I'm always aware that this is a very expensive activity, because I'm actually trying to use my eyes as a data mining tool. It's never the most effective way to do data mining. I definitely don't want to do the same thing twice. In this case, let's go and find it. I'm going to afford to do it because I only have a single screen that I'm looking at. When I screen quickly, I can see there's an error message here that points much closer to the problem, when it was trying to download some executable, and then it couldn't do it. That's the one that I would like to highlight in red, so that next time, I don't have to use my eyes data mining that I could quickly see where the pattern is. I'm going to do exactly that. I'm going to dive into this now Step. I have a Step object here, it has a console. Then, if I look at the implementation of this view, now I have the implementation. I see source code. This is the source code that defines that view. I can see this is a text editor, and that it shows a piece of text that is actually coming from the log. Then this text editor also has a styler. That's the styler probably that is responsible for this coloring. I'll actually take a look.
The Console Styler
I'm going to browse the code of the console styler. I know that typically stylers like that have this privateStyle method over here. When we look here, this looks like a parser. In there, there are some patterns and transformations. I want to build a pattern exactly like that. I'm going to build another one here. I should say self, noGTVersion, and text. When I do that, it tells me, let's create that method. Indeed, let's create it. Now I want to go and find exactly what I should write. Basically, I need to put the same error that I saw as a parser. Then I'm saying I wanted to highlight that one with red. I'm going to save this. Now when I go back to this step, and I execute this, I can see that this one is properly highlighted in red. The same thing, next time I'm going to have the same problem. I will click here, and I'll see here, that's going to be red. I won't have to read again. That's basically how the flow of moldable development is. We see a problem, and then we construct a custom tool to capture that problem.
The Inverse Flow of Moldable Development
If we take a step back, and we look at these two kinds of problems here, apparently they are not the same kinds of problems. On the one hand, we have some architectural static analysis type of problem. On the other hand, we have something with APIs and a monitoring situation. They would be considered as being two different kinds of verticals, yet we have approached both of them in the same way. Which means that they can be a way to look at problems, rather than looking at them through the lens of tools that we're given, to look at the problems in a uniform way, and make the tools adapt to that perspective. That's the inverse flow that moldable development proposes. We literally apply this one to every single development problem we have, whether this is a business problem, whether this is a data problem, whether this is an architecture problem, some API, or any other problem. We will always look for what visualization, what browsing would make the problem easier to digest, more explainable, simpler to grasp. We're going to stop every time something doesn't feel comfortable, and we're going to build a custom tool.
Moldable Dev through Wardley Mapping
Perhaps let's take a look at moldable development through the lens of a Wardley Map. Every problem in moldable development relates to some challenge. It can be either purely technical, or it can also be related to the business. For example, if you take a look at splitting into components type of problem, the management of toggles can be technical, on the one hand. On the other hand, it can be a business problem. For example, if it's a business imperative to split the system to scale it, it is important to communicate and have a conversation with the business to why this is challenging. You need to have a conversation about the inside of the system, about those technical details that otherwise pretty much remain inside the black box, and that you'll often cause communication issues.
A challenge is always about a specific problem. The goal is always to reach some decision. In a typical case, a specific problem usually is supported by some view. These views are often put together manually. When a view is put together manually, it documents, not so much the system, but what the author of the view thinks the system is. It's a very interesting documentation. It is not the same as knowing what the system is. Why do I say that? It's because the system is simply too large to know. It changes too often to rely on memory as a useful tool. The problem many times when we meet teams that want to reason about their own systems, it's not so much that they lack the knowledge of knowing what to do. What they lack is an ability to see the problem. These manual views are put together through some manual inspections, by people either reading code or talking with people that have read some code. That is never complete. Instead of this, we don't want manual views, we want generated views. In our case, we use a couple of these views that were produced automatically by the tool. Of course, to make that generated view to also be valuable, it needs to be contextual. It needs to relate to the specific context. That's where this specific coding comes into play. We're transforming this effort that we would typically spend on inspection, into a bit of coding. Once we produce this code, then we can generate the view.
Of course, we can immediately say, we're going to build a tool, and then we're going to use that view many times over. That was the case, for example, with the build. We want to use that styling many times over. In the first one with the toggle, we're probably going to have that issue, not very often, not necessarily. It's particularly problematic when we want to split the system. Once we're going to split the system, it's maybe not going to be that interesting afterwards. There are cases where a tool is useful exactly just once, and it's still economically viable. Why? Because the biggest economic benefit doesn't come from the fact that we are reusing the view many times. The biggest economic benefit comes from the fact that we are going to base a decision based on reality, based on exactly what the system is right now. That's the major shift in how we think the energy in software development should be spent. Why is this important? This is important, because, right now, developers spend the largest amount of their time and energy on figuring the system out. Most of this is actually spent on some manual inspection, often reading text. That never scales, so that has to change.
Why do people actually go and read? Because they want to understand what's inside, but because the tools are too rigid, and they pretty much only show you the same static perspectives over the system regardless of which part of the system you're looking at. You're going to be forced to use a malleable tool, and that's reading. The only problem is it doesn't scale. The way to change this is to change the nature of the tools, make them moldable, that is, empower, or build into the environment the ability to quickly change the shape of the tool to match the current focus of development. Through that, we can create these kinds of custom views automatically, and empower a new decision making. That's the essence of moldable development.
Background Info
My name is Tudor Girba. I'm the CEO of feenk, where we're focused on making the inside of software systems explainable.
Questions and Answers
Kerr: That was a big jump from, here's this cool thing. Here's how they come together to represent a completely different philosophy of development.
Girba: Indeed, we think that this is a way of thinking that fundamentally changes, not only the productivity side of it, but also how we feel during development.
Kerr: How we feel? You mentioned feeling uncomfortable as a trigger.
Girba: Absolutely. Every time we see a problem that we're not comfortable solving, we're going to stop and make it comfortable. We want the problem to feel great. To the point in which we do the following experiments, we sometimes tweet pictures of bugs, like how the bugs look like inside.
Kerr: You mean software bugs?
Girba: Yes. For example, the one you've just said. You said, you have two cool things, and one of them is actually a picture of a problem. It's a failure. The one with the built. That's a failure. There's nothing glamorous about a failure of downloading a file from somewhere, and seeing it in a log. Yet, we could tweet that, and other people will retweet that. That's the crazy thing.
Kerr: Tweeting about the failure? Why is that? Why do people tweet that?
Girba: Because it's cool. Because the inside of software systems can become cool, everything about software can become incredibly pleasant. For example, when we ask people, do you love working with legacy systems? It never occurred to anybody that the inside of a legacy system can actually feel beautiful, but it can. We have to change the way we look at it. We just have to change the lenses basically. We haven't changed the system. We haven't changed the problem in any of those examples. We actually have a decade of similar examples behind us now. In all of those cases, it's not the problem, the system is not necessarily the problem. The way we look at the system is the problem. That's something we can affect.
Kerr: Every system needs a different way of looking at it?
Girba: Every single problem needs a different way of looking at it. For example, in our little system, which is not a very large system, we have more than 1000 different views, individual views. More 1000 different little plugins.
Kerr: These are the custom tools that you've made.
Girba: These are the custom tools, yes. They're little tiny ones. For example, even in the little demo that I showed, you saw a couple of views, but they were repeated. The individual views is one, but the fact that you can concatenate them live, and can even affect them through code, basically gives you the opportunity of creating, we think, into millions of visual narratives about anything that you have. Compare that with the typical experience of take a screenshot of a development environment, go to another developer, and take another screenshot of their development environment, they work on a completely different system. Keep those two screenshots 1 meter away from you, you're going to have a hard time distinguishing which is which, because they're going to show the same thing.
Kerr: Because they just look like an IDE?
Girba: That was an IDE, the one you saw, but every problem looks different. The colors are different, the shapes are different. The way we communicate, not through the text, we use our ability to actually associate different shapes with different meanings, in particular here. Every time you have a little query, you're embedding in that query, how you want the summary to be like. It's like that query is the legend of your intent. That's very powerful.
If you're always going to use a default query, you're just not using the very thing that makes developers unique.
Kerr: Are you saying that people's pictures would look different, because they have different mental models?
Girba: Absolutely. Even for every single problem, we might have different pictures, like different people will communicate differently.
Kerr: Because you'd need a different map to view this system from that perspective.
Girba: Absolutely. Then this one has a very deep impact, so have far-reaching consequences. For example, one of the surprising things that we noticed, one-and-a-half years ago, was when the pandemic started, we realized after a couple of months that nothing really changed for us, because we were working in the same way before. Not only were we working remote, we worked remote in a strange way, so no meetings, no schedule, no different planning in a centralized form. The thing is that everything changed for the individual, but nothing changed for the organization. That was like a striking thing. Then we said, how did we get to this? It was not exactly what we were looking for necessarily, being prepared for a pandemic. Because if I say no meetings, no schedule, everybody remote, everybody works exactly when they want, how they want, what they want to work on, it sounds chaotic. If you look in any management book, you would say, what's that kind of work? Because you need to synchronize people. We only have a chat as a tool for communicating. We are a team of less than 10 developers. We were sending about 10-plus pictures per day on Slack, and they were not GIFs. All of those were actual pictures, like these ones, like the one that you saw in this presentation. These visualizations. What those pictures do, they actually compress communication.
Kerr: You're saying that you had much higher bandwidth communication even through a simple chat interface, because what you're sharing is visualizations rather than just words.
Girba: Absolutely, because of all of those things that management puts in place to deal just with the goal of synchronizing nodes. If you look at organizations, it's distributed actors, and every meeting is a synchronization. Everybody stop, and we should have the same state. That's always a bottleneck. What if we can increase the bandwidth of communication between those nodes, all of a sudden, the whole economics changes. We have new models in place.
Kerr: You've done this by increasing the bandwidth differently with a different visualization for each problem that you're communicating about? Not one generic mechanism.
Girba: Yes. We are a consulting company, or we found ourselves as a consulting company, but our goal is to create these new ways of thinking about software. We've invented moldable development, but also creating Glamorous Toolkit right now.
Kerr: What language do you develop these visualizations in? What language do you develop them about? I saw some Python going by.
Girba: Glamorous Toolkit is implemented in a language called Pharo, which is a Smalltalk dialect. We are basically handling all sorts of different input. We saw Python, like the usual suspects, JavaScript and different frameworks of JavaScript, or Java, or C#, or even C++, or Qt even. We found ourselves through consulting projects. We do two kinds of projects. We work with two kinds of situations, one, either there's a company in some crisis, "Here's a big legacy system. I don't know what to do with it." The other scenario is, you have maybe 20-plus years of people working with that system. Then you have to come in, and within weeks, you have to tell them more than they already know. It is a crazy thing. It should never be possible. If we understand engineering as a field, this should not be possible.
Kerr: To generate that much understanding of a legacy system so quickly. We have that same problem with Honeycomb, that problem of, did you know your system is doing this?
Girba: I'm sure you do. This is one of the kinds of customers. The other kinds of customers are those that seek for competitive advantage. When we start a project, for example, looking at a legacy project, we don't even ask what languages it's written in. We usually solve business problems. We solve the problem at the business level. When we talk with managers, they don't know.
How do you do it? It's because Glamorous Toolkit is a language workbench. When we see something that we don't know, like a new language, we're going to build the parser, and it's still going to be cheaper. We're going to do it almost live, within days. Sometimes they don't even know the language. For example, we worked once with a very core system, they thought it was written in COBOL, but it was written in some variation, which was a macro language on top of COBOL. They didn't know. This was a very large corporation in Europe. This was one of their core systems, and they didn't know the language. They gave us a documentation, but it was wrong. It was useless. Their input was useless. We had to reverse engineer the language, then on top of it, start figuring out the systems.
Kerr: Is the goal of this to build a single shared mental model of the system amongst all developers?
Girba: The goal, first of all, is to enhance. Our ultimate goal is to solve what we call software environmentalism crisis. The software environmentalism crisis looks like this. The body of software grows exponentially year over year, but we are unable to recycle all systems. That's unsustainable at the society level. We are just not able to get rid of systems. People are just talking about the latest version of React, but we still have COBOL around.
Kerr: This is the problem that there's cumulated levels of software that are running in production, and people are depending on them, but no one understands them anymore.
Girba: The only option people have is create another black box on top of it. It's crazy. People are talking about the metaverse, and it's funny. What is not funny is that our kids are only going to know a world of software. We messed up one world, we shouldn't mess up the second. There is a way to make this one work. For this, we have to understand, what is the bottleneck? The bottleneck is the fact that right now, the way people read or understand the system is basically limited by the speed at which they can read. It's very slow. That's what we need to fix. To affect the large things, you have to affect the smallest thing. Is the goal to get the team to build a simple mental model? Absolutely. Until you get there, you need to make it profitable for a single individual. That's where the biggest work here is. You don't have to get the whole buy-in of the whole team to get the benefits of moldable development at a single individual level. Of course, what we want is not only to get the developers on board, we want to get the business on board. How would it be to have something like this, business comes with a question, you go into a pairing session. Then open the development environment and answer the question live, and the business person understands, and goes away.
Kerr: Because there's a visualization that fills the problems.
Girba: There are ways to transform anything in software in a way that some other human can understand. You might not know exactly what that is, but there is a way to find it out. It sounds a little bit strange, but it's not something that we haven't done before. I realized this one when I once opened my electronic banking interface about 12 years ago. It looked very ugly. It was always an unpleasant experience. I thought, it's because I'm paying bills. Then at one point, they changed the interface, and I paid a bill and I felt satisfied. I was like, what an amazing achievement this is? You can take something that is inherently a negative thing, or should be associated with negative feelings, and you transform it into something that feels great. That's just computation there. Any boundary in a system is arbitrary. We can take the same lessons and apply them on absolutely every single level in a system.
Kerr: Clearly you spend a large proportion of your time building custom tools to explore the problem domain. The human instinct is that that sounds inefficient. What have you found?
Girba: You must write.
Kerr: It sounds like you would.
Girba: That sounds like that, but it's actually totally the opposite. We make this work, because it's economically viable. I'm not talking about the moral things. I'm talking about profit. At the end of the day, bottom line, you get more profit. If the team doesn't want to listen, or if the business doesn't care, the individual finishes early, and goes off, done. That's it. That's the benefit. This is not more expensive. In fact, it is many times cheaper than reading. That's the only reason. Proportionally, per day, we probably spend the largest amount of our time building tools, but we're going to answer an order of magnitude probably more questions than anybody else that does not build tools.
Kerr: You're able to make the right decisions faster of what to change in the code?
Girba: Absolutely, and more confidently.
Kerr: Instead of using your eyes to data mine.
Girba: I've seen people that made their mind very quickly, but they were wrong.
Kerr: Make skillful decisions more quickly.
Girba: Yes. The confidence, and then be right about it. That's the interesting thing.
Kerr: Be able to say why this is.
Girba: The why, because that's basically what gives you the confidence.
Kerr: More than say why, but actually show even a business person why this is the thing to change.
Girba: Exactly. There's the bottom line. Literally, this can become profitable. On the other hand, it's immensely pleasurable. It's unbelievably pleasurable. At an individual level, it's amazing. We've been practicing this one for years, and it's still surprising.
See more presentations with transcripts
