#213 - Moldable Development: Explain Systems & Make Better Software Decisions - Tudor Girba

Do you agree with the statement that you spend more than 50% of your time reading code? Pretty much everybody says yes. But then I ask another question. When was the last time you heard developers talk about how they read that? Nobody talks about it. If you don't talk about something, it's not explicit. If it's not explicit, it has never been optimized. Why do you read code? Well, you read code because you want to understand enough a system to be able to make the decision.

What if we just look at software engineering as a decision making activity rather than construction activity? Software is highly contextual. As a consequence, we cannot provide clicking tools as solutions. They won't be effective. Nobody can read the whole system. It means that most information that we will basing our decisions on are going to be inferred. So beliefs.

Basically, whenever people Draw Something on the whiteboard about the existing system, they depict their belief about the system rather than the system itself. This is the essence of multiple development. We're going to build tools through which we read, and then we're going to make decisions on that. But these tools will provide an unmediated lens through the

system. You mentioned in your writing with Simon Wardley the problem with legacy system, why it's going to be a big challenge for us. Right now we create software faster and faster, so year over year the software grows super linearly. But we're unable to recycle all systems, so we behave no differently from the plastic industry. It's not sustainable generative AI if you use it for generating arbitrary kinds of code, as people are trying to do.

As long as we as humans decide we want to understand what happens inside the system, we have to solve the reading problem. There is no way around it. Hello everyone, welcome back to another new episode of the Tech Regional Podcast. Today I'm very excited to have this conversation. We are going to learn something new, a new concept called moldable development. So I have Tudor Girbell with me today. So I'm very excited to have this conversation.

Welcome to the show, Tudor. Well, thank you for having me.

Right, Tudor, maybe before we start diving into moldable development, I'd like you to maybe tell us a little bit more about yourself by, you know, sharing some career turning points that you think we can learn from you. OK. Well, so I'm presently the CEO of Think. Think is a company that is focused on modernizing legacy systems.

We exist since about 10 years and the reason Think exists is because we wanted to have a way to fund the research that led to what today is called multiple development. There's interest in researching the space of how do we reason or understand systems and make decisions about systems leads back to a couple of decades in my case. So I started with my PhD and work at the University of Bern and postdoc then. So my my research area was software analysis, software evolution, mining systems

visualizations. So I was building quite a number of tools as and there was an extensive platform at the time that helped us prototype analysis very fast and lots of them. And at some point I remember writing my NTH paper starting with this sentence that developers spend more than 50% of their time reading code. And then I realized that the oldest reference on the subject that I knew of was something around it was from around 1979,

which was about 3 decades back. So I was wondering if I can state exactly the same problem 3 decades later. Is it possible that we are asking the problem in the wrong way or looking at the problem in the wrong way? So I started to try to look at the problem differently and then what was worse was then I looked at myself. So I was a researcher and I was building lots of tools that were supposed to automate and help developers understand their

systems better. But when I looked at what I was doing, I was reading code for more than 50% of my time. Obviously something was not quite right and so I tried to solve problems afterwards. So I left academia to try to pursue this idea. Finding a different way. To look at how to improve decision making, software engineering and so. We knew how to build. Tools. We did have this extensive platform already in place at the time it was called Moose.

It was one of the largest platform in software analysis research at the time. Several dozen PhDs worked on it and lots of master students as well, and several universities. So I was the main architect of it. And so I, I started to do consulting and tried to solve actual problems. And when I realized I was looking for the recurrent pattern, because I didn't know exactly where to start from. And I, I was looking for the

recurrent pattern. And then I realized that the only recurrent pattern was that in order to be meaningful for a specific system, our specific problems in a specific system was that I had to tweak my tools. I had to change my tools. That was the recurrent pattern

over and over again. And that's when these other observation came into play, which is the software is highly contextual, which means that we can predict classes of problems people will encounter, but we cannot predict the specific problems that people will encounter. And it so as a consequence, we cannot provide clicking tools as solutions or we can't provide them. It's just that they won't be effective because the clicking a clicking tool makes the problem in the click.

So if I can't know the specific problem, I'll be answering the generic problem. And so the rest of the energy to actually go and answer a specific question about my system will have to be filled somehow. And it typically happens manually. So the alternative is to say, well, what if we can build a tool after we know the problem, which means during development. So that was the idea about 15 years ago. And ever since I tried to validate or actually we were

looking for the counter example. So he and my colleagues, that's what we've been doing for the last 15 years, searching how is it possible, Is it possible to tackle every single development problem through a custom tool? And then is there a counterexample when building a custom tool is not desirable? We haven't found the counterexample yet.

This episode is brought to you by Swim dot IO and I'm excited to have its CTO and Co founder Omar Rosenbaum with me today to tell you more about Swim. Hi Henry, very nice to meet you and thank you for having me. So tell us a little bit more, what is swim dot IO? At Swim, we want to help companies understand their code bases. We combine static code analysis with generative AI to create comprehensive documents that help you navigate the code base.

As an engineer myself, I wouldn't want them 10 years to spend so much time understanding existing code. I would want them to spend time creating and building new stuff. When you have code that has accumulated over decades, and especially in legacy languages that not many people are adapted nowadays, then the problem is even bigger. Swim dot IO is specializing into helping mainframe developers to understand their coupes. Why mainframes?

We actually didn't start there. COBOL had been by some people obsolete for a few years, and I discovered that it's not really obsolete, not at all. There are more than 800 billion lines of COBOL code that are in production and they drive lots of the business in the world and we got more and more requests. From. Customers to help them understand the legacy code business that was written decades ago and get accumulated over a very long period of time.

So from your customers so far, what are the some of the success stories that you can share? So we worked with an analyst who shared with us that it took them a year to document a single mainframe application, and using SWIM they were able to document a similar application in a matter of hours. So saving that amount of time enables them to focus on other tasks. Thanks Amir for sharing with us about SWIM Today. To learn more about SWIM, check out their website at swim dot IO.

Well, I think you shared very, very interesting facts, right? Let's start with the first thing that you shared, right? You mentioned that 50% of our time, I'm most kind of like developers, right? I think we spend more than 50% even now with AI, right? Because AI suggests more code than we wrote, we are reading even more, right? So I think reading code is definitely the main job of a developer and not just that actually to understand how the

software is written. Because if your software gets bigger, right, you won't be able to understand just by reading one file or few files, right? You have to read maybe the edges of those files that you're working with.

So maybe tell us this problem that probably we all experience it, right? But somehow we kind of like what you say, right? Use this generic tool, clickable tools, Ides to actually understand the code. Tell us why this is not really optimal? Like what kind of examples that you can give us why this thing doesn't work for longer term? That's a nice question. So they're very interesting studies over this going back a couple of decades and measuring what developers do.

And they all show that this, the amount of time we spend trying to figure the system out is way up beyond 50%. Now, I wasn't satisfied only with that, so I actually went and directly talked with more than like several 1000 people, several 1000 developers, and I asked them directly in various situations. And I asked him, do you agree with the statement that you spend more than 50% of your time reading Cloud? Pretty much everybody says yes.

So I was at the O2 a couple of months ago and there were like 500 people in the room and I asked this question and then everybody said yes. But then I asked another question. When was the last time you heard developers talk about how they read out? So not about the code that they read, but about how they do the reading. So it's a weird. Question right, what's there to talk about right and it's. Nobody talks about it. It's not such a conversation.

This is kind of interesting. Because you were talking. You were asking why is this suboptimal? If you don't talk about something, it's not explicit. If it's not explicit, it has never. Been optimized. Now normally, let's say when you're searching, when you're trying, let's say you have a running system and you're trying to optimize performance and you profile your system and you find like a big chunk, like more than

50% of the performance. In a single place, in a single piece of logic and you looked at it and you look at it and say, wow, we've never optimized this algorithm. Now this is like a super great news because now I can optimize a great deal of it because there's a very large promise of optimizations possibility right there. The same thing happens with activity. Like literally when we don't. Talk about what we do for more than. 50% of our time, that's the single largest expense we

have. There's nothing larger than that. It basically means like we. Just we're going to optimize for the tiny bit. So we have this humongous amount of work and we're just going to optimize this little tiny thing that we do.

And this is by the way, right, talking about AI, that's what happens. Like people just say, oh, what are we going to use AI for? I'm going to. Generate more code. So then of course what happens is the problem just becomes even larger. So that's the first order logic, the first reason why we should actually start talking about it. We don't even. Have to talk about the solution, right? This is just such an obvious place to start optimizing.

So that's basically where I started from 15 years ago to look at it as an up to a conversation. And so now what, how else, you know, can it be more optimal? So for example, in the AI worldwide, we say, oh, we have this like we, we see these demos, right? As everybody talks about how I generated an application, of course the application is only 10 screens or so, but it's basically you're bombarded by this, you know, walls of text and people say, oh, look, so great.

It's like what? Like how? How do you know? Because it's just, you just have something there. So, so you have to go and read it is a way to reason about. But in fact, that's the thing, you don't have to read it because the reason the question is why do you read code? Well, you read code because you want to understand enough a system to be able to make a decision. So a situation around the system to be able to make a decision. Now from this, the activity is

actually decision making. Now, given that social engineering is primarily like this is what we do most of the. Time and AI. Just makes the problem more obvious. The problem exists at its scale well before AI. So in any organizations we meet, people are drowning in software that they cannot move, that they cannot understand and change. This problem existed for a long time. We've been able to optimize more and more. The thing that we talked about, which was how do we construct systems?

So we got better and better and producing more and more code faster and faster and faster. And now to the. Point in which we generate some, I don't know what code, and we're going to just say, Oh yeah, put it in the production. So this one got better and faster and faster and faster, but this other problem just became larger and larger and larger and we're not talking about it. So we definitely should be talking about it, the first thing to say. Here is that given that.

We spent so much time trying to make decisions. What if we just look at software engineering? As a decision making activity about an ever changing system that is much larger than it fits in our heads, rather than a construction activity. Now when you change the point of view, lots of things change. Lots of things that were important before all of a sudden become much less important because now you have a different perspective to look at it. So this is the first. Thing.

So from that point of view, reading, for example, is just a strategy. It's just a tactic. Actually of extracting information from the system right now from this point of view it becomes obvious, but actually this is the most manual possible way in which we extract information from our system. So you see, like once we make this subject obvious and we start. Talking about it. We do like two or three. Steps and we just. Find ourselves in a rather like,

what are we doing? But then it gets even crazier because if you think about what's an enterprise? System doing for example, right? So all enterprise systems, they automate someone's decision making specifically by preventing those people to ever see the raw data. So we take the data, we import it, we model it, and we present it in a way that other humans can make much faster decisions about humongous amounts of data without ever seeing the data.

So who possesses the skill of transforming, you know, raw data problem into decision making problem? We do like software, people do. So when software. People have their own problems. What do they do? Well, we fall back to the most manual possible way of doing things. It doesn't make any sense. So. But the cool thing about this is. So there are a couple of things here and one of them is that we have a large opportunity for optimization because you have these like very large costs.

It was like obviously we're doing something that is so manual. So it's like very, very good news. Because we just a little. Bit of investment in that space probably can put you ahead of things. But the other thing is that there's a significant probably, you know, like this is just a small investment can lead you to a significant short term type of benefits, but it's more very likely that you can have layers of that. So just on this thing.

But the other one is we shouldn't just be looking at the cost. So when we say this is the amount of time we spend trying to gather the information, we should be also looking and what do we do with the result of that activity? Because the decisions that we make is a consequence of reading the cup are much more costly than the time we spend actually reading the code. And this is where it becomes really exciting.

So today, for example, it's actually very rare to find a team that is able to provide an accurate depictions of their system. So let's say you know, an architecture diagram, people will be presenting architecture diagrams, but then I always ask them. So like usually those are manually put together. And so I asked them, would you bet your salary that the diagram is actually real? And nobody would take the bet because it would be, everybody knows.

Yeah, but it's not expected to be actually that real, right? And then the question is, well, why not see if you take this as the basis for any decision making, shouldn't it be real? And put it the other way around. I'm in an engineering space, right? I'm not betting on, you know, what's going to happen tomorrow. I'm, I'm in an engineering space where I'm trying to build systems that are kind of reliable and are meaningful and they produce some value.

So not knowing what the current system looks like, probably not a good variable to have. So that's what we're saying is that well there is a systematic way to know about your system at much lower cost than it happens today. And this then has far reaching consequences.

This is the essence of multiple development is we're saying we're going to take this time that we spent today or the developers spent today reading and we're going to take some of it, some of this effort. I'm going to build tools through which we read and then we're going to make decisions on that. But these tools will provide an unmediated lens through the system because often people say, shouldn't we trust, you know, technical people that they know what they're doing?

We should trust technical people. There are some problems that shouldn't be decomposed or seen as trust problems. So an example that I always give is, let's say that I'm interested in what's the temperature outside. Is that a trust problem? Should I go and ask someone and trust that someone? Or is it just should I go and look at the thermometer which is outside my window here and if I look at the thermometer which is outside my window, does it mean that I'm not trusting the person

next to me? No, because that is not a trust problem, right. So now the the issue with reading is that nobody can read the whole system. So if nobody can read the whole system, it means that most information that we will basing our decisions on are going to be inferred. So beliefs basically. So the consequence is that at some point your beliefs will be significantly, you know, apart from the actual, the reality of the system and you'll find yourself dancing around the fire

to make rain happen. So it's, it's really like that. So for example, we we're writing a book with Simon Worley, which tries to summarize what we've learned about multiple development. And one of the case studies that we're showing there is an actual system. It's an important data pipeline in a significant telecom company. And their issue was that this pipeline was too slow. So everybody knew it all the way

to the C level. They had a large initiative demanding that, well, we should improve the performance of this one, but like significantly, let's say an order of magnitude or so. This is what they wanted. Now they worked on it for three years and after three years, the performance was exactly the same as it was three years before. And so it was like somebody looked at the problem and says, well, how come? So when we looked at the system, we asked them what could you draw the system for us?

And then they drew four boxes and said these are the data pipeline looks like. So the way we always look at the problem like that is we're going to build a tool that shows us that system kind of like data science if you want, like we start from the problem and then build a tool specifically for

that problem. In their case, they had like custom made technology that was doing transformations and the local platform that didn't have any kind of analysis tools and so on. So we had to build interesting analysis tools so that we can recover some sort of data lineage. But while in this process, very soon, we went back and said, well, you know, like the output from the first box doesn't seem to match the input for the other

ones. And then we asked, so Are you sure you don't have another thing here in between? And they discovered the whole system that they were not aware that it was there. And and it has nothing. To do with the ability like engineering necessarily abilities directly, because these were like good engineers. The problem is that when you work in teams and silos right when things move between, the most interesting problems are always in between the things that you already know.

Right. So if you're not prepared to see those interspaces, you're going to miss the interesting opportunities, right? So the issue in their case was they could enumerate 4 things and they had actually 5. But if even at this large coarse grain level, you're not able to see the whole system, you're basically in no position to optimize anything. So it doesn't matter how much effort you're going to spend because the problem is not, oh, are you able to change? The problem is I don't see the

system in the 1st place. Even if I'm convinced I'm actually understanding my system, I'm not seeing it. Once that's the case, that's the first problem to solve. And I would say, OK, but this sounds like such a ridiculous case. But you'd be surprised how often this happens even in places where which people say, oh, I actually have a much better grasp of my system. You'll go and ask a few couple like more detail.

Go to three levels deeper and you'll find yourself in the place where people Draw Something on the whiteboard. Whenever people Draw Something on the whiteboard about the existing system, they depict their belief about the system rather than the system itself. This is really important because if you can't distinguish between these ones, you're going to find yourself being in a make belief space and then your actions will have no impact on the reality. Yeah.

So I think so many interesting things that you mentioned just now, right? So I think one major insights that I could listen from what you just said, right? Software development is actually kind of like a decision making process, right? And I think through writing code, you know, through syntax, through whatever programming language that you use, it can be suboptimal, right?

Because whatever that we want to create, we are kind of like limited by the tools and the kind of like the thing that we express ourselves in, right? And I think we all know as a software developer, once you get to write your code in a longer time, it's very, very difficult to actually understand what is going on, especially it can be very abstract, right? And so many people working together in the team, some are new, maybe some have left, maybe even like they don't talk to

each other. So there are so many different ways of how software is being written. And I think this is going to be a challenge, right? And plus, you may think that AI will solve it, but AI, you know, that could also hallucinate by reading your code, right? So some of these definitely is optimal and I can really understand because now I'm currently, even though I'm currently working in a small startup, right?

We have written code for, I don't know, the past few months, there are still things that I think I don't fully trust myself and knowing the system end to end, right? Just like what you mentioned, if we asked to to come up with an architecture diagram, yeah, we can kind of like draw high level picture, but we are never sure because the code is the fact, right? So sometimes the code doesn't reflect what you believe, like what you said.

So I think this also leads us to another thing that you mentioned in your writing with Simon Wardley. The problem with legacy system, like does it here, I think doesn't just refer to old, really old systems, but software that you wrote maybe a few months ago can also be categorized as legacy. So tell us this legacy problem, why it's going to be a big challenge for us. So we've internalized this idea that once we write the systems, we can't really make sense of them anymore.

Not really. So in rare occasions, man, there's actually like people are very like very joyful. But the vast majority of situations of the reports out there. So we for example, in the book released, I don't know, a paragraph worth of all sorts of different kinds of reports from that we took from industries, blog posts and reports here and reports there. Of course, those are not necessarily super systematic, but they all point to exactly one problem.

Like legacy is everywhere and it's very expensive and it's very hard. Like all these reports saying, oh, 7080% of or whatever the number is of the migration projects are, are failing, right. And that's really like the reason if you look back into why this is the case, it's because we don't see the system. The interesting thing is that as far as people see the system, they have no problem making better decisions.

Absolutely no problem. That's the the great thing about this is that the skills already are in house because we we just have to apply the skills that we use to automate other people's decision making. We just can't apply them to our work. It's pretty much like that now. The thing with legacy? Is you're right, like legacy doesn't necessarily have to mean very old, but in fact it shouldn't even mean something that is bad. Legacy should have a positive meaning, right?

So in everywhere else, like legacy has this positive connotation. You want the legacy of most of the time, right, But not in software. Software people hear legacy. It was oh, so for example, one other question I asked developers, he said, well, do you love working with legacy systems? And people definitely don't associate legacy and love, you know, they don't find a sentence that would make make these two words work together in the same time at the same time.

So, and that's a. Problem because legacy means value. It is the thing that produces value right now. Now the other thing about systems is that right now we're looking at systems often as just transforming input into output. So this is one way I call this one a utilitarian view on software systems. However, most software systems have replaced some sort of manual work that happened before, and we used to call that

work knowledge work. So obviously these systems, we can also look at them as encoded knowledge when you look at the system as encoding knowledge, right? And then we start to talk about knowledge management. So that means exploiting the knowledge, internalizing an organization to create a new value.

Then all of a sudden it means it's kind of important given that in any meaningful software organization, the core knowledge is not in people's heads and is not in documents and not in emails or other forms of communication. They are in systems, which means that any knowledge management based activity has to start from the core system, from inside the system. And that's the opportunity. And today people look at legacy systems and they see, wow, this

is an impediment. It drags me down, I can't move right. So This is why incumbents have difficulties when newcomers come into a space because they can't move their systems, while newcomers don't have that problem until newcomers become large enough and then they have the problem with the new space of newcomers. But if you would be able to change the system fast, then all of a sudden the legacy would become a competitive advantage and not an impediment. That's where we want to be.

So today, whenever people talk about legacy, they just talk about large costs, very high risks, and the difficulty of ever seeing inside. And I think we should be moving in a world where legacy is actually a positive thing that we should be able to change it and will. So this is one of you from an organizational point of view, First of all, just see a single organization point of view.

The idea would be take legacy from something that looks like a negative on the balance sheet to transform it into a value creation opportunity. Let's take an even larger perspective here. You know, let's go to like societal level. So right now we create software faster and faster. So year over year the software grows super linearly, but at the same time, we're unable to recycle all systems. So from this point of view, we behave no differently from the plastic industry.

It's not sustainable. And So what does it mean to recycle a system? Recycle means to take it apart and refurbish it between your purposes. But of course, before you can take a system apart, you first have to understand the parts. But if the way I understand the parts depends on me reading and I have a fundamental problem because reading is kept at a constant speed. So on the one hand I have a super linear growth, on the other hand I have a constant recyclability function.

It can't work. It literally cannot work. So it's not sustainable. So the only alternative here is to make it so that I can read it about my system so I understand the parts, regardless of how large the parts are and how large the system is. So the only way to achieve that is through tools. But now of course we had these other problem with of course we want the tools. The problem is that software is contextual. So the only way to solve this problem is by making tools to

also adapt to that context. That's again leads us back to the same little tiny thing. So, you know, this little tiny detail of, oh, where, what do developers do? Look at how many implications it has. On the one hand, we talk about large costs associated with it. On the other hand, we talk about is this the opportunity for creating new value like business on the business side? Can I refurbish my system for that?

But now if I just take an even larger perspective, I see, well, it's actually not sustainable and we're moving the whole economy on top of software. At least this new world should be sustainable, because we still have difficulties making the old world kind of work. I think very, very interesting perspective, right? So I think when we talk about legacy, we always associate it with bad things, you know, a lot of technical debt, very difficult to change. We just need to rewrite it, right?

So that's always the excuse of developers. We just need to rewrite it. But obviously, like what you mentioned, I fully agree, the challenge is actually to understand the encoded knowledge inside the code inside the system, right? And it could spend, you know, across multiple different places, right? And for me in the past, when I joined a new organization, a new team that have existing system running, right?

In the past, what I tried to do is basically to use instrumentation, you know, going to observability world, you have telemetry, you have metrics, you have probably all these trace spans that you can understand how the system interact with each other. Sometimes if the tool can generate, you know, like automated diagram, that's also one way how I did that. But it's never fully enough, right? Because it's always challenging.

And sometimes if you have access to the data, you can also deduce it from the data, but we don't know just by looking at data, also not fully accurate because it's just the output, right? You don't know how it comes up, the calculations and all that. So definitely this is a challenge. And I kind of laugh when you mentioned we are like a plastic industry. We keep churning software, but we cannot recycle them. I think it's going to be a major challenge if we continue this path, right?

Though maybe let's go into the multiple development, you know, maybe workflow, let's say, right? So for people, because it's still sound abstract for some of us, so how would you explain, you know the workflow working with multiple development? So you let's start with something you already mentioned. So let's start with

observability. The interesting thing with observability, of course you can put the the default metrics you know and monitoring and so on that level CPU and disk usage and tells you something, but not really interesting things, right? But then you can start to have, oh, let's add some signals which are maybe technology specific

all over this. I can start to learn new things like which services are being used, but then I can increase the specificity of it. Well, let me add the main specific, like business specific kind of signal. So then I can, you know, answer business problems you like how the business flows actually are representing my system. So that becomes really exciting. But notice here how the value increases with the specificity of the signal. So that signal is a little tiny analysis.

There's another place where we use little tiny analysis. This is testing. So in testing you have a problem and then you stop, you write a test and in the test you say, well, this is the setup and this is what the condition should be. This condition captures value. This assertion here says this is valuable and the consequences that as soon as a single test fails, people stop and fix it in most of the time today, right. So you're not going to deploy if the if the tests are not green.

So that's pretty nice because you're stopping the line to deploy even if a single test fails. Now if you switch. To let's say for example, static analysis, again, static analysis like a test is nothing with an analysis tool, right? It just takes functionality and transformed into red and green types of things. So it's kind of interesting, right? But static analysis is also an analysis. It takes something, in this case takes static source code.

It also produces red and green type of thing if I look into a range rule or something. But then I can have. Systems where I have, you know, thousands of tests or 10s of thousands of tests, all green and then I have on these other places I have 10s of thousands of warnings. How come is it like this team all of a sudden, you know, lost interest in qualities like what happened? Like they have two minds. Like like, why is it? Well, The thing is, just look at the.

Difference in how these two analysis have been produced. So the tests have been created within the context of the system. After you know the problem, the static analysis typically is downloaded from somewhere. So you're downloading it from your system for your system. And I don't know, you're doing, I don't know, maybe banking or so. And I'm working in embedded systems. If now all of a sudden we're using the same analysis, you use the same, I use the same.

So by definition, that analysis must capture what's common between us, which also by definition, it doesn't capture what's interesting about our systems. Of course you don't want to mess up nulls, you know, send create no pointer exceptions. Of course you don't want to do that. But that's such a terribly low value, right? Like you're living, the rest of the 99.99% of value creation right is left completely unchecked. So these things the static. Analysis that we download from the web.

They solve a problem, but they literally solve someone else's problem. So the alternative is we can take the same thing that work for testing, the same thing that works for observability, but it literally applied to everything, including the tools that we look through. So not only checks of sorts, but also the tools that we visually view things or edit things through. And this is also kind of interesting because it. Leads us to into the development experience base.

At the very beginning, you mentioned the IDEI in IDE stands for integrated, which basically means every time you leave the environment, the eye has fed. And today, like people use these things, which they're called ID ES, and they spend like 70% of the time in the web browser. This is really funny. And then The thing is, right. The question is, well, how do you make this development experience work?

And one thing to realize here is that you cannot experience anything in a system except through some sort of a tool. There's no way for me to sense anything in a system. Maybe if I'm looking at the code, maybe I see an editor? Or if I'm looking at an object, maybe I was going to see any object inspector or something like that. So there's always a tool in between. But the interesting thing is, I mean, what's something we know from data science now is that if you just change the way you.

Look. You don't change the data. You just change the way you look at it and you can fundamentally affect the way people make decisions about it. And this ability, the ability to control the thing we look through. And this also includes the signals you observability, the static checks, but also like visualizations, queries against the code. And not only against the code, but against what if my system is built now in multiple languages and it has a service oriented

architecture? And maybe there's also a bus in the middle? There are messages being sent there. And if you look. At how those are captured in the code, there's no dependency between this. You know, the message name is going to be some string somewhere and that's going to be

pushed. And then somebody will going to read that string and is going to say, yeah, you just send me a message, which means that there's a dependency there, but we don't see it. If I just look at the base language, I don't see anything there, right. But if, on the other hand, I can, if I elevate the tool to understand my framework, for example, the framework that I'm using, all of a sudden I can start to see things that were

completely invisible before. During the pandemic, for example, we donated our time for a government and we built an app. So we helped build an app, but we use the React Native. But we didn't, we didn't know React Native beforehand. So we had to learn and we had one month to produce the app. So we spent, I don't know, a few days to learn React Native. So we did, and we started to build components. It was not a complicated app.

Maybe the second week or so, we ended up with the dependency between like the cyclic dependency between React components and we said, OK, well, so React is only the most used framework in the world. So obviously we think maybe others have that problem and surely, surely enough, right, they do. So you're good looking to stake overflows of the world like there's lots of those kinds of problems. How do I deal with the?

Particles, but at the. Time we said well OK, so again this is a very widely used framework. It looks to be a rather often occurring problem. Surely there must be some tools that will help us detect these cycles. We didn't find any, so the people. Have the time. And just think about this, is take overflow right? The proposition of take overflow is I have a problem in my system. The. Thing that I chose to put together tells me. Here's the error. And the best possible

engineering solution. For me is to take this. Problem. Go and ask it somewhere else and hope that someone that has never seen my system will give me the interesting answer. This is absolutely. Not engineering right? So to me the. Success of stock overflow and stock overflow was asking until a couple of years ago this interesting question, which was what's the first thing you? Do and you have a problem? And it was always, I think there were a couple of years where

there was, you know. Do you Google? 1st Or do you go to a? Stakeover flow directly. So which one is? It was not clear and it was like 90% people responding. This is the first thing I do when I have a problem. So that's literally like there's a. Huge chorus. Of people really crying for help because that's not an engineering way. Right. We shouldn't. This should be like the losses, or sometimes maybe you want to go and debate and so on. But they should not be the first.

Thing we think about. So when we had that. Problem. What did we do? Well, we stopped. And we built the tool that would show us here the components in React and we will being able to click on a component and see, well, here's what it is. So even this simple thing, right? So if you think about your development, your, your editor, right? So what I like about Visual Studio Code is how honest it is, right? It doesn't sell itself as an IDE. It just says I'm an editor. Which is really really.

Nice and honest. So in an editor you typically see files and the source code. I just described like in the React application. I really want to see components. I'd want to see files. Files are very low level. This is the like. The lowest level in which I'm storing data. Why would they want to look in the database and just see a record by record? Like why would that be an interesting view of things, right? So what I really would like to see, I would like to see an index of components.

It's a very basic thing I should have an expectation for because we don't talk about it. We don't. Expect it, so I don't like to do. That so we may have a problem with components. You want to see the list of components. OK, here's the list of components. If I can see the list of components and if I can say, well, this component depends on the other component. This is the other crazy thing if you think about oh, JavaScript. Is very weakly typed. It's hard to do static analysis,

that's kind of true. But if you look at React, that's hard coded type. It literally says this component. If hands on these other components, it's like the names are right there. There is no look up there sort of thing. It's very, very concrete. So you can actually build very cheaply at all, really gives you the graph of components. It's not difficult. But this mass hallucination space that we live in where we say, oh, I don't know what to do. I go over and ask a stack

overflow. You don't do that. Stop and look at all and look at the opportunities that are around you and you will see actually going to stack. Overflow is the. First thing, oh, OK, now I'm not going to go to Stack Overflow. I'm going to just type in because ChatGPT is much closer. So I'm going to ask, oh, what are those right? And ChatGPT will tell me oh here are the components but you have no way of knowing if these are all. Components or not. Maybe they are, maybe they're not.

But there is a way to use? For example, something like ChatGPT. Will say, well, what if you ask ChatGPT, could you give me a tool that I can run, a small tool that I can run to list all the components? And maybe if I say, oh look, actually you missed this one over here because you know, like they're not just one way of defining components. For example, nowadays in React,

you can have several ways. So now if I find this exception here, maybe I go and extend my tool, maybe with AI, maybe without AI, but the idea of having an unmediating inspectable. Deterministic way to answer questions about the reality of my current system is really simple and is incredibly powerful. And that's the essence of multiple development. We're simply saying now imagine you have the possibility to create custom tools for every problem you have.

That's the essence of multiple development. Now this of course means those tools have to be creatable at much lower cost then we consider tools to be created today. So when I say much lower cost, I mean minutes cheap. So within minutes I should be able to create an increment that gives me some sort of added value. Maybe it's not the end of it, but if I spend minutes, I should I want to say something that produced an increment and I can decide whether or not I go left or right.

So now this means that I now need a whole new kind of a development environment that makes it whose first job is to make the creation easier, because anything that comes out-of-the-box solve some problem, but is almost guaranteed to not be my problem. So this is more interesting for a development environment to start asking not how do you edit this, but how do I create a new tool that is highly specific to

what I want. And so this leads to a new kind of a development environment, but also implies new kinds of skills because now I would have to have the skill of creating the tool, ideally within the organization, within the team. But even more interesting is the skill of asking questions. So today, because we answer questions very slowly, we're going to ask very few questions, interesting questions about the

system. And because we ask few questions and far apart, the muscle that is the muscle of asking questions atrophies. So we find ourselves asking kind of generic questions and they're very difficult to act upon and very difficult to answer. While what we want to do is we want like if you think about, OK, here's the question, here's the answer, and then here's the next question that comes.

So if the distance is very far between the question and the answer, the distance between two questions going to be very far. But now imagine that I can decrease the cost of of an answer to be almost 0, not 0, but very, very close, many times faster. All of a sudden the bottleneck will be, oh, how do I come up with the next interesting question and the next interesting question and the next interesting question? And so the skill of learning how to build tools. So of course you need the

environment. You need something where you can create tools very quickly. And when I say create tools, I mean thousands of tools. When I say thousands of tools, I mean thousands of tools persistent. So little tiny micro tools that coexist and they can use to assemble narratives about my systems very quickly and pretty much on demand. So if you just think about this, in my world, I, I've seen, for example, a large organization, like a large Unicorn and they had thousands of developers.

And then when we looked at the tools, they used dozens of tools. Right now, OK, in my organization, my team, we are a dozen people and we use 10s of thousands of tools. And so it's similar, right? Everybody uses tools, but not the same way. It's kind of like when people were saying, oh, we do some testing, you know, we do some automatic testing. So for these 5 cases here, this is automated, but the rest of the 10,000 scenarios are not right?

Or when we're saying, oh, some parts of the deployment pipeline was automated. Yeah. So there's like some automation and it looks like deployment, but it's not the same as when you have a deployment pipeline that you can use 10 times per day. It's like the properties are not the same. So that's what we're saying. And so you need this technology to allow you to create and host and effectively use such tools,

maintain them. You need the skill of creating the tool, but the most interesting and important skill is going to be the one that is about asking questions. Yeah, in your article with Simon Wardley, you mentioned about time to question, time to answer, right. So I think that's very critical, maybe the critical thinking skills that people are talking about lately with the at the end of AI, right, we are losing our critical thinking.

So maybe asking questions and getting the answers is definitely still gonna be the main core skills for developers. And actually when you mentioned about cyclic dependency, I kind of like remember my recent experience actually I was working with a Nest JS back end system, right? And we have the concept of modules and service and all that, which also has a cyclic dependency kind of problem.

But I could actually solve the problem just by subscribing to their tools, which they call dev tools $5 a month just to visualize how module interconnect with each other. So actually I kind of understand what you're saying, right? So imagine if you have all your files, all your classes and all that, but you can visualize it differently, maybe through different type of micro tools that you mentioned, right? Maybe you could even visualize and solve the problem faster.

And best case is like you start generating more questions like how can I improve the system? Or maybe there are the parts of systems that I would like also to know about, right? So I think this is definitely very exciting.

And you come up with this tool called Glamorous Toolkit, right? So maybe a little bit shared with people, how can they use glamorous toolkit, what kind of things that they need to do in order to come up with this micro tools? It's interesting that you mentioned, right? So you have a framework. And apparently people that build the framework came up with the idea that they should also build tools that understand the framework. I mean this is. It should be so common

knowledge, right? But The thing is, even when you don't have the $5 per month or. Day or whatever possibility. It shouldn't mean that you're hopeless. It should still be within the realm of possibility to literally build your own tools. So we as a tiny, tiny team, I mean, we were like 4 people. So four people decided, oh, you know what? Like we see this very large problem, everybody has it, but it's economically feasible for us to spend the day and build a tool.

I think we have a tool that shows me the dependencies and cycles between my components. And then The thing is that, you know, tomorrow you will not be using a very commonly used tool and maybe you'll not just be using 1 technology, but you'll be using the combination of things. And all of a sudden, then what? There is no off the shelf. There is no. $5 per month type of opportunity so you. What do you do? Oh, you're going to go to Stack

Overflow? So there should be a space to continue where I say, well, what if for any question I have, there is an economic way, an economically feasible way to go and answer questions. And so that's what Glamorous Toolkit is. Glamorous Toolkit is a free and open source environment that we have created. Well, this is a really. Crazy idea if you look at this status quo right? Like what I'm saying here, thousands of tools like how do you maintain these people say?

Oh, are you not going? To be bombarded by too many tools. And the answer is yes, you can maintain it very quickly or easily and cheaply. Actually, it's much cheaper than if you don't build the tools and yes, you're not combined, you're not overwhelmed by thousands of tools because you don't see thousands of at once. You'll see them one of those that are meaningful in the specific context, so. It was a really crazy.

Idea a decade ago and so the the current incarnation of glamorous toolkit we started about 2017 and the goal here was we want to create a vehicle with which we're going to explore how far this idea. Can go and. So the way we set up was that if we are going to exist in 10 years, it means that multiple development works. So, you know, when you're doing your own validation for a new idea, you're going to be biased, right?

So it's obvious if I say, oh look, I've done this one, I applied in a case, it works brilliantly. Everybody should do exactly this, right? So that's we see that it economically works in all sorts of situations, but not often necessarily, you know, it's not necessarily grounded in reality. So we really wanted to. Validate before we're going to go, so thing was created 10

years ago and we still exist. And the way we created it was we said well, OK, we can't do unbiased type of validation because we'll have to do the validation ourselves. So what we're going to do is we're going to create the most adversarial type of situation we can imagine. And if we can survive that, then the only way, the only explanation would be that this notable development works. So Glamorous Toolkit is among those. Everything we do is free and open source.

Glamorous Toolkit is a significant piece of technology. It's used in production in different places. We made it completely free and there is no, we don't have any means to charge it. So people can just download. It and work with it, but when I say it's significant, I also say, well, we've actually used it in. Dozens of different classes of problems. So not problems, but like classes of problems. So when I say, you know, like classes, I mean how do I reverse

engineer an API? How do I reverse engineer a protocol? How do I make a distributed system and reverse engineer and move it to something else? How do I reverse engineer architectures? How do I reason about the domain and make business answer? Like do explainable domain driven design directly from the system? How do I do data lineage? How do I do DevOps and observability directly from there and all using the same kinds of?

Tools and techniques and what they what we are showing and when you open Glamorous Toolkit. It comes with all like a book. A book of the size of Harry Potter written inside. In the environment, because it's a knowledge base, it's a data science platform, it's a programming tool. But this is not like a classian does it by just stitching together different tools, but just having a really common design. Because these are not different

spaces. And what we're showing is that it's possible to tackle really, really different classes of problems exactly in the same way. And the promise here is if you can do that, it means that you can invest in the skill once and then use it over and over again in all sorts of unforeseen types of situations. Now, when we build Glamorous Toolkit, so we used it as a vehicle for us to explore. But at the same time, Glamorous

Toolkit is the first large. Case study of multiple development if you look at something like IDEA Intellij. And you look into the plug insurance marketplace. You will have something like 6-7 thousand plug insurance worldwide. Then you move to Visual Studio Code, and I think last time I looked, it was they had like 60,000 plug insurance worldwide. When you open Glamorous Toolkit built by a tiny team, you have more than 4000 plugins in the

core. And these are the tools that we used to develop the platform itself. So when people are going to use Take Glamorous Toolkit and use it for another system, they're going to be building thousands of tools more. Per system, not worldwide, per system. So the EBRANCE Toolkit is the.

First, major or a significant case study of multiple development itself, which means that you can use it and you can take it and use it for solving actual problems, but you can also just take it and use it and say well. What does my multiple development mean and simply learn from it and then maybe copy it in other places? Our only worry? Is that people will not copy the whole of it. Because this thing has. So many implications, so many interesting details, and it can

be so powerful. It's not just about how you view things, but also how you create editors for different languages, how do you combine different languages, how do you deal with data in different formats, and so on. So on the practical. Side, the way you work with that toolkit is it's based on small talk, so it's an image based system. So you basically download it and then you customize things. Sources are all in GitHub. So you can also create your own customizations put in next to

your project. So you can take and build like a Docker. You can take a base Docker, create, put something into it. So take the base image, put something into it and save it. And this is going to be the distribution for your system. So this is how it is the way you learn it. We advise people to to split learning in two phases. On the one hand, learn how to learn and then afterwards learn for a specific problem. And this learning how to learn is really interesting because.

As I said. GT Glamour Toolkit was built following multiple developments, so it has explanatory tools inside. So it has a way to search for example. Inside has the way to understand, like different objects will have different ways to visualize it themselves. So learning how to jump from one tool to another, it's kind of important. And the other thing here is if you think about tools that you typically think about. Features.

So you might be learning things like shortcuts by hand or, or by heart, or you'll say, well, this button does this, this button and that, right? There will be dozens of buttons to learn. Or really like 100, OK, but in our case, we have thousands. And then when I start to combine them, I have an explosion of possible combinations of things. So it's not possible to learn them by heart. Instead, what you want is you want to learn what's this?

How do you decompose each problem in the same way? That's the most interesting thing. And this is how we can scheme to arbitrary situations and actually not overwhelm people. Sounds really interesting tool, right? So definitely, we'll put it in the show notes for people who are interested when you listen to those explanation just now. Sounds really cool actually, if you can actually come up with different ways to answer questions about your systems, right?

And speaking about tools these days, I'm sure people use IDE, right? Not just simple text editor. And people now have AI tools as well, either chat base or maybe the cursor or whatever that is, right? It's more like a genetic AI and I'm sure this Grammars Toolkit is 1 potential tool. Although the attraction probably we still need to see in the next few years where do you see the future of our development environment, right? Do you actually see IDE AI and Grammars Toolkit living side by

side, collaborate? Or even can we use AI to come up with those micro tools? Well, so first of all, Grammars Toolkit is a development environment. So you should see. It's just that it doesn't look like any development environment because typically we open a development environment and what do you see? A giant text editor in front of you. What are you going to do, right? You're going to scroll through it and try to learn, right? There's not even a search box.

So the in our case, right? Because anything is the last thing I want to do, not the first thing I want to do. Just think of this. What does it mean when I say I said at the beginning, we don't talk about how we read code. Where do people read code? Well, in an editor, It literally wasn't made for reading. It was made for anything. It's a different use case. It's similar. It's really different. So the question is, why should you see an editor as the first thing?

I don't know why though. We used to have, for example, Yahoo was heavy. Oh, here's the tree of all the interesting pages. And then there's the other guys will come and say, well, what if I just give you a search box? Much more interesting as an interface, right? And then nobody was saying well where is your tree. But I still remember actually people asking that question, where is the tree? Well, you might not be

interested in the tree, in fact. So, yeah, so I think that that if you optimize, if you take seriously this idea that we should be optimizing for decision. Making. The nature of the tools should change. They shouldn't be. It's not an increment. It's a really, really different kind of perspective. So Lammers look it is a development environment, but it's a development environment which you can create other development. Environments now, I do believe. AI has like generative AI is the

way we see it today. It's very interesting not to be in the way that certainly people look at it today. So I really think that as long as we want to be the ones making choices about what goes into production, we have to solve the reading problem. There is no way around it, because otherwise we're just going to pretend, which is exactly what we're doing right now when people pretend to work and then three years go past and nothing changed.

But then at some point, some people will exploit this new opportunity of using our leveraging the human intelligence and they will transform this one into a competitive advantage. And this will become the new norm just like how DevOps, right? So even today, we still find people that are still now automating their deployment pipeline, but they will be automating right after they'll put automating testing in place.

There's going to be a long tail of those cases and it's the same thing I believe will happen with the way we optimize decisions. So with AI is very interesting. So if you use it for generating arbitrary kinds of code, as people are trying to do now, I think that this, the appeal there is right. So the local platforms are in trouble or they have to become AI. But low code never really displaced the interesting systems.

As long as we as humans decide we want to understand what happens you inside the system, we have to solve the human problem, the reading problem. There is no way around this because literally today we humans or engineers and business people are starved for information. People don't see the system you literally don't have like your brain can work. It doesn't matter at which speed because you don't have the input. So you don't know what's what's in there.

So when you're asking. The AI right? The other use that people use AI for is. Oh, we're going to use. AI to summarize a system for us. The problem with that is that again, you don't know what of it, what of the answer was left out and how covering is this one. So basically you're replacing. Someone's drawing on the whiteboard with this one, but their beliefs in both of them, but they're not quantifiable. And so that is not an interesting way.

I think it's very appealing, but it's not really an interesting engineering solution. On the other hand, if you ask an AI to say well. Could you create me the tool? That I can run. To see these dependencies, for example, that I believe is very interesting because those talk can be really small. But then of course, now all of a sudden I want to create lots of those tools. Where should I be creating lots of those tools for any of my

question? Then all of a sudden you want to demand, oh, I need to put somewhere these tools. So I will be demanding that my development environment should be hosting these kinds of tools. So maybe all of a sudden this editor just giant text editor I have in front of me.

Is not the most interesting. Thing at all to see so I'll be demanding that you know what I should be able to have a different kind of a development environment there that allows me to have an engineering conversation with my system and then once you see they say well actually you know what if the cost of a tool is actually so tiny that the blocker isn't the creation of the tool but is the asking of the question the rule was sending actually the AI is just that it's interesting

optimizations but it's nothing but an optimization so that's what I see because at the end of the day it doesn't matter who creates the code it matters who has to make a choice about that code so either we're going to delegate everything to an AI and I can see lots of incentives for doing this just like how people this kind of trading which is completely unmediated by humans today algorithmic trading and I can see this one being

extrapolated and there will be classes of problems where people will want to do that like for example spam. I think they are thriving today. There are classes of problems where this would work but there will be classes of problems where I don't see this current technology ever doing this other kinds of advances. In technology. Might change the equation. But the current.

One, there will be interesting, very large areas of economic value creation where the human will have to decide, and then that is the problem that we actually have to solve, right? So I think that's really insightful explanation, right? So how probably we can see a potential future where maybe AI glamorous toolkit, multiple development, right, working side by side and we solve different class of problem.

So I noticed also recently you kind of like Co wrote a book with Simon Watley. You also mentioned it in very beginning. Maybe can you tell us a little bit what's the mission here? Like why are you writing the book? What are you trying to come up with Simon, right? And what are you trying to

explain to people? Yeah. So first just to. Wrap up on the AI and Glamorous Toolkit. In Glamorous Toolkit, for example, we think AI is really interesting, but the way you're going to consume the output of the AI is really important. So we're actually doing research and there is an infrastructure in Glamorous Toolkit directly to work with AI but create on demand interfaces to consume the output of the AI.

So for example, I imagine starting a chat and just having a generic chat interface and then while chatting to customize how the messages are being proposed to you. So if if you're seeing something by default these days, when people say, oh, if I show you a picture, it's like this. What if I want to see the hex of the picture, right? Or if the encoding or something like this or so I might want to choose different kinds of representations.

And so that interface controlling the tool through which you look has lots and lots of implications. This is a bit, maybe what I'm saying here is a little abstract, hard to believe. I understand that. And that's the reason why we're writing this book. Simon and I, we worked for several years together and since about a year, he chose to work much more closer with us.

We basically spend the whole year trying to find ways to explain what it is that we discovered in our research and in our work in a way that is more consumable. So something that abstracts a bit the technical details and find a way to explain to, for example, a CTO or CIO, maybe CFO type of level as to why is it interesting to look into the legacy space, How do you create value? How can you create value out of it? And why the development experience is the answerable.

And of course, to explain on multiple development, that's a little bit of the background. So definitely good luck with the rest of the chapters that you're writing with Simon. I read all the chapters that you have so far, right? So I must say it's very interesting. It gives a lot of background and kind of like the problem challenges we are facing. And I'm sure we gotta learn a lot more about multiple development in the future.

Tudor, it's been a pleasure to help you with the show. I have one last question, which I normally ask to all my guests. I call this the tree technical leadership with them. Think of them just like an advice you want to give to us. Maybe if you can share your version of tree technical leadership with them. I think I'll just stick with. One one of them which is simply start to spend 15 minutes a day as a developer looking for how else.

Would you be able to find an answer to a problem that you're looking at right now? Don't try to necessarily do it, simply just think about it. And then what you will see is that after. A couple of days you will start to notice opportunities popping up around you because the interesting thing about whenever something is not explicit, your eyes are not trained to see interesting things related to

that. And I think this is an interesting problem in any case, because it goes into this idea that whatever you're training, that's what you're going to use and teaching yourself going through a more inconvenient experience as like everybody else is doing something. I'm just telling you, you're not right. Go ahead. And not to do what everybody? Else is doing try to think how would I? Possibly answer this question here, but without reading a line

of code if possible. And sometimes it's not exactly possible, but many times it is. You might find it around you. And so this exercise I find is an interesting exercise, especially with newcomers in programming because it teaches people to start to train the ability to see things that are

not obvious at 1st. And the other thing that he trains is the idea that engineering is a discipline that doesn't follow hypes, hypes, hypes, they go engineering changes all the time, but it really doesn't, right? And there can be a systematic way to discover it. And so that's what I would urge you to do it. So think how you would think, right? So it's kind of like meta level. So I think it's kind of like

beautiful advice, right? So I think we could use more critical thinking and also kind of like probe the system that we have, right? So that we can understand it better. And maybe there are opportunities like what you said, how we can improve it so that our software can be recycled, not like the problem that we are having now. So to know if people would love to connect with you, maybe they want to ask you more questions. Is there a place where they can find you online?

Well, yeah, so of course, you can find me on LinkedIn, I believe at Gerba on LinkedIn, and I invite people to just connect with me and directly ask questions. You can go to glamglamoroustoolkityoucandownload@gtoolkit.com. There's also a Discord community there. And if you're interested in what we do as a company and how we modernize legacy systems, go to fenk.com. So FENK comes from feel and think. Yeah. Find more details about it

there. I like it feel and think think.com right so if people have modernization challenges, you can contact to the. Just wanted to say that hidden thing comes from the fact that know how to think in our world, right? Or we think we do, but we forgot that the way we feel is as important as the way we think, right? And if you come back to this problem of how do people feel when they are in the presence of legacy, I believe we should change that. Really nice name behind it, right?

So I think for people who are interested in multiple development, make sure to check out to those resources. And I hope you have more traction in this space, right? So looking forward to see the future where we are coming up with our micro tools. Yeah.