Revolutionizing Software with Moldable Development

Intro

Julian Wood: Hello, and welcome to another episode of "GOTO Unscripted," where we speak to some of the amazing speakers who travel the world as part of the GOTO conference circuit. And today I'm joined by Tudor Girba. Tudor, welcome to "GOTO Unscripted" How are you today?

Tudor Girba: Well, I'm fine. Thank you for having me. Nice to meet you.

Julian Wood: Nice to meet you, too. We were due to record this at GOTO Copenhagen, but technical issues abound, so we weren't able to do it. So, it's nice to actually finally meet you in person. Tudor you did a talk, which you have done at GOTO, about moldable development and about sort of software and tools and all these kind of things. But I mean, you have a PhD in software and you've been sort of developing models and tools for software evolution, it seems like forever. So, how did your interest in not just necessarily developing software, but developing tools to understand software start?

Tudor Girba: I guess a little bit of serendipity. But, yeah, just as things happen. So, I eventually ended up doing a PhD at the University of Bern. And the main focus there was, or one of the main focus was on finding models and tools for making or helping people understand software systems faster.

The Genesis of Moldable Development

Julian Wood: So, was that the initial challenge that you defined that people couldn't understand software initially? And you sort of felt that well, there's not one tool that can do them all, you need lots of tools. So, yeah, what was the genesis of doing your research?

Tudor Girba: The basic idea, the basic setup of doing reverse engineering, software analysis, software evolution-related research is this little statement that we know for about 40 years now, which is that developers spend most of their time reading code. And that understanding the inside of software systems is actually what occupies the largest part of the development effort. So, there's been no shortage of energy being spent on this. And the way we approached it at the University of Bern was we built tools to support our research. And so in the end, we kind of built a platform that allowed us to experiment faster with all sorts of different perspectives, visualizations of different sorts. And it was a great deal of fun. And in fact, it was at the time the largest platform in software analysis research, lots of PhDs worked on it. And I happened to lead that work at the time. And then at some point, I said, "Well, definitely we should go and try this one into the industry a bit more," and I switched.

I remember actually the motivation being, I was starting my end paper with the same sentence, "Developers spend more than 50% of their time reading code." And then I looked at what I was doing and I said, "Well, I'm spending more than 50% of my time reading code." And then I said, "Well, is it possible that there's something that is systematically wrong in the way we look at the problem?" Because when you have a systematic effect, then something must be wrong in the way you look at it. And then when I started to apply tools to try to solve problems that I found in the industry, I started about 15 years ago to do that. The one thing that got repeatable that I noticed is repeatable was the fact that I had to tweak the tool to be relevant. So, then there was this other observation. Usually, we need tools because reading is so manual. And then there was this other observation that software is highly contextual. And because it's highly contextual, it means that we can predict classes of problems people will have, but we cannot predict specific problems people will have. Now, clicking tools, tools that you click on, they bake the problem in the click.

So, which means that in order for the tool to be actually relevant for the problem that you actually have, you have to build it after you know the problem, which means you have to build it during development. So, it turned out that all the research that we've done for how do you make the experimentation for new techniques faster, was very, very useful and created the premise for what we today call moldable development, which is we brought this idea of, can we bring the construction of a custom tool to be practical during development? And it turns out that it is practical and it turns out that it does introduce a new feedback loop because it automates the largest part of what people spend today as code reading. So, when I was at GOTO, for example, like, a month ago or so, I asked the audience if they agreed that they spend more than 50% of their time reading code and pretty much everybody agreed.

Recommended talk: Moldable Development: Programming Through Custom Tools • Tudor Girba • GOTO 2024

Reframing Code Reading: Optimizing Developer Tools

Julian Wood: So, do you think that's a problem that people are spending more than 50% of the time reading code or the fact that they need to read their code but they could speed it up by using analysis tools to be able to understand the drive and having to read all the text that's in the actual programming language? Is that the sort of challenge? Or that...

Tudor Girba: Exactly. Yes, it isn't the time. It's the way. Because I asked two questions, right? I asked them, "Do you agree that you spend all this amount of time reading code?" They say, "Yes." Now, 50% or more means it's the single logic expense we have. There's nothing larger than that. So, if we can optimize that one significantly, we have a significant impact over the overall outcome. And so then I asked the second question, which is, when was the last time you talked about how you read code? Because as soon as you want to optimize something, you have to make it explicit. If you don't talk about it, it's not explicit. If it's not explicit, it has never been optimized. That's the problem. And that's in fact, in my mind, the largest problem we have in software engineering today. That's the one thing that we should optimize.

Julian Wood: That is interesting because I think even parallels when you're talking about reading code, obviously, you know, code is very difficult to understand when you do read it because it is, as you say, contextual. It jumps all over the place. You've got, you know, APIs or data analysis, all these kinds of things. But even analogies, I was listening to another podcast recently about people talking about, you know, speeding up the way they actually learn to read books. And also, you know, the way that people used to read books for ages. Now, people listen to books at double speed and they can actually take in a lot more information, you know, and optimize everything. My sort of recollection is like, "When I learned to read, I don't think I've ever paid any attention to that." Can I make my reading more efficient in some kind of way? And so, yeah, I think this... You know, and this is always, I think, super important because these are things we take for granted. You just realize you have code there, it needs to be read, it needs to be understood. Of course, there's documentation with that. But that's not everything you can do, correct?

Tudor Girba: Yes. But so now indeed, speed reading is important and, you know, one should definitely invest into doing this because, you know, you get information faster into your brain. So, that's great. Except that code, right? So, speed reading will, you know, maybe they have, let's say, if you read really slow, maybe you can multiply it by a factor of, I don't know, let's say, 5X. It was really slow before and now you're going to be 5X faster. But let's say that you have something like a million lines of code and let's say that you read already reasonably fast, let's say one line in two seconds, and you can keep at it for eight hours per day. It will take you about four months to read the whole thing. Not to understand, to read.

Julian Wood: To read. 

Tudor Girba: Just to read the whole thing. So, the problem with this is that, even if you make it, let's say, four times faster, it's still going to take one month to read the whole thing. And it changes multiple times per day. So, at least maybe, you need about two more orders of magnitude easily. So, this is not the way to do it. And the problem with not talking about how we read code is because we never get to challenge the reading part. We assume that we have to go and read. And that's interesting because that behavior actually correlates with the interface that we are faced with. So, for example, if, you know, we ask people also, for example, how do you find things in the code, right? So, querying could be one way, but whenever we talk about querying, people at most are not going to use some regular expression. But then of course that one treats the system that's with the code as being just plain text.

And so is there no better way to do it? And people say, "But this is so hard to write queries against code." And so we have these other exercises in which we give people a schema, you know, a database. And so we'll write a query over this. Let's say, for example, you have a company and the company says people, people have a relationship with other people that are in other companies. Can you tell me which company has a potential relationship to other companies? And people have, you know, it takes about 30 seconds for people to put the query down, maybe 2 minutes, but that's pretty much it. No problem. And then we ask people, "Okay, could you please, for example, change companies with class and people with methods?" And now you just wrote a query over the code. It's not the problem of skills. It's a problem of just people believing something because it's not explicit. It's never been optimized. Now, that's just a basic idea.

But what we found is that so much of the reading is in fact, the search problem. It's just essentially spending the time to find the thing that is actually interesting to read. Some sort of reading we do need. We're always probably going to want to rely on it. It's just, it's a tiny, tiny fraction of the overall effort. Most of the other things is abouthow do we get the overview. And that's not a reading problem. It's a visualization problem. It's a search problem. And now if you look at the tools that people are exposed to, why is it that people can easily work and write a query, or get this database, but not against code? Well, it's kind of interesting how this, you know, if you think about the two interfaces, the database tool has a big query box at the top. So, what do people do? The first thing, they're going to run through the query there and then going to see the data. What does an ADE have? A giant text editor presenting you with text. What are you going to do? You're going to read.

And so if you change this, it's kind of interesting the corollary here, right? We know about this relationship between the tools we use or expose ourselves to and the way we're going to think. We know about this all the way, you know, from Marshall McLuhan, who was a philosopher in the previous century, and who looked at the introduction of this new medium, of the digital medium into society. And he said, "Well, how is this going to affect society?" And then we have this, then his work was summarized, one way of summarizing that was that is this idea that we shape our tools and thereafter our tools shape us. Which also means now that if we get to... We have to be very careful with the characteristics of the tools that we expose ourselves to because they're going to influence the way we're going to think. So, then we say, "Well, it turns out that there's a whole science of what that tool can be." That's what moldable development is, is a way of taking charge of your environment. And at the extreme, the idea is for every single problem we have, every single development problem we have, we want to make the tool fit the problem, not make the problem fit the tool. It's a simple idea, but it's a complete reversal from the way typically development happens today.

Recommended talk: Software Architecture for Tomorrow: Expert Talk • Sam Newman & Julian Wood • GOTO 2024

Moldable Development: Customizing Code Visualizations

Julian Wood: Okay. So, just sort of practically visualize this. We were talking about visualizations. If someone is in their code editor and they have, you know, a Pope base or, you know, whatever kind of language and a whole bunch of code, you know, do they point the tool at the code? Does the tool then analyze the code? How does that work for you in your IDE? And you want to create, use moldable development to get some insights into your code to understand it. What does that look like if I'm a coder in front of my work on my laptop?

Tudor Girba: So, first of all, if you're an editor, if your development environment is almost synonymous with an editor, you might want to consider a completely different track. So, in our development environment, which is free and open source, and it's called Glamorous Toolkit, we built it actually for several reasons. But one reason was it was a vehicle for us to explore this idea, like how far does it go? So, itself is a result of being a moldable development environment and a moldable development case study, because it was built following this. So, when you open it, you have thousands of little perspectives in it. There's thousands of little tools that we've created. And then now back to your question, like what happens when I have a problem? Well, before I choose the tool, I first start with the problem. I don't find myself in an editor. And then I say, "Well, how do I read my way here?" I first say, "What is the problem? And is the editor even an interesting place to be?" And many times it isn't. Many times other sources of information are more interesting.

Maybe I just want to get an object in front of me, get the whole system with runtime, and just take a look at that particular object. Sometimes it is the editor, but many times it isn't. And so now in the end, we wanted to say, "Well, but how do I change the way I look at one object?" Not even in a class, right? Or an editor for a method or a class, but just one instance. And then if you go to, like the way you look at it, for instance, you have this tool, which is called an inspector. And in most environments today, that's what you get when you put a breakpoint somewhere, you're right, you get a debugger, and then you see your objects there and you click on one of them and you have a tree and you have two columns, variables and values. That's kind of interesting because now, with that tool, you can represent any object anywhere in the world. So, you build it once and you use it billions of times. Now, this is such a cool, you know, reuse in such a profitable way to look at it. If you look at it from a tool vending perspective, right? On the other hand, given that that tool can show me anything, it doesn't capture anything that is interesting. It shows me how the object is inside.

But if I, for example, look at an object that shows me a webpage, a URL, it would be kind of interesting to actually see the rendering of that webpage. If the object shows me a file, you know, in the file system, it would be much more interesting to take a look at how that file is, right? But it could be like, just take the file, for example, right? So, let's say if it's a picture. So, looking at it through the rendering of that picture is one way. But then if you say, "Well, where is this file located?" Well, another view that shows me the position of that file within the tree of my file system is a much more interesting way to look at it. So, the picture is not relevant for that question, right? And if I want to actually decode, then maybe it's not a picture, maybe it's a zip, and then I want to decode what's in there or some sort of encoded byte, you know, a byte array file, then having a hex view might be more interesting. So, all of a sudden, there is no single perspective, even for tiny objects.

There's no single perspective that is interesting, that's unique and captures everything that we want to know about an object. And this idea turns out, it's actually pervasive and it can be applied to anything. There is no single thing in the software system that can be only seen in one way. So, then all of a sudden, the question is, "Well, what should an environment look like so that it can accommodate all these kinds of perspectives?" And so, as I said, in our environment we have thousands of views, thousands of actions, and those can be created live while you look at things. You say, "I really would like to create a new view on... So, before I'm going to approach any problem, I mean, look, do I already have a tool that is interesting for this context?" And if I don't, I'm going to go and stop and build it and then continue with my problem. So, that's the flow of moldable development.

Recommended talk: Simplifying Dev Environments with the Right Tools • Christian Heilmann & Julian Wood • GOTO 2022

Creating Tools on the Fly

Julian Wood: Okay. So, you mentioned also earlier about moldable development being you are molding these tools as you are sort of creating them. And then you've just mentioned that you find a problem, realize you don't have an existing tool, and then you go and create the tool. So, what does that look from a practical perspective of, you know, where are you jumping to create the tool? In my mind, I'm also thinking, "You must be overwhelmed by the tools you have and you've found the tools that you already have and you're going to create new ones." So, yeah, how does that just work in a workflow?

Tudor Girba: Obviously, anytime you create a tool, right? You always have those, it implies another meta-level, right? So, you have a problem to solve, and now I'm going to create a tool that's going to help with the problem. The same thing you have, for example, when you do a test. The test is an analysis. I have a problem. I'm going to build a test to look at this. And this is expensive. And so having two levels of abstraction in your head is kind of expensive. So, what you want is what you want to bring when creating an environment that makes the cost, the meta detour to be as small as possible, right? So, this is why tests became pervasively adoptable when the cost of creating a new test became too small, right? So, it became so small that basically, it doesn't count anymore. And therefore you can pervasively use tests. The same idea applies to anything. What if you can take minutes and create a tool, minutes, and create a perspective? Then all of a sudden you can approach every problem in that way without thinking in advance about, you know, the profitability of it.

That's because the idea is that if I can advertise the cost of a tool on the first use, I don't need to use it the second time for it to be profitable. So, then I'll always build it. And that's the idea. That's the goal of the research, of how do you bring the cost of tools to be as small as possible? And so now once you have this one, then you go to the second question. It's like, what happens when you have thousands of them? Well, so, as I said, if I would just be exposed to thousands of views at the same time, that would be useless, because I'll just see noise. On the other hand, as I said, software is highly contextual and each of these tools were created to work in the context. So, now it means that if I have an environment that shows me or surfaces, the tools, based on the context where I am in, then all of a sudden I don't have the problem because I'm not exposed to thousands of tools at the time. I'm exposed to a few tools at a time. And that's how you deal with this.

Julian Wood: The tool then has the context of the kind of things you're searching for. So, I know one of the examples, everything you know, it's like browsing APIs, for example. You know, it's a sort of visual thing. People want to see, you know, a route coming into an API and where it's maybe incinerated in code. So, if you are looking at an API spec or are looking at some code that represents an API, the rest of the tools can also all fade into the background because, you know, you're not doing data analysis or that kind of thing. You are looking at your API. So, is that how it sort of...

Tudor Girba: That's dangerous.

Julian Wood: ...that dynamic visualization of how the tools can be relevant?

Tudor Girba: Yes. And it's also not quite unlike how you have billions of web pages, but you're not concerned with them because you only look at some things at the time. So, that's, it works perfectly fine, right? So, you can jump between one to another and it still works perfectly fine because it gives you have an environment that just serves you the visuals that are relevant in a specific context.

Glamorous Toolkit

Julian Wood: So, the GlamorousToolkit just sounds like the most fabulous name ever for a bunch of toolkits. I think that's how it comes into being. Where did the glamorous part come from, because I love it.

Tudor Girba: Well, the glamorous part came from the... Well, we asked, you know, one thing that this is not the first time at the last GOTO, it was not the first time I asked developers these questions. You know, do you read code and when do you talk about it? But I also asked other questions. For example, do you enjoy working with legacy systems? People rarely associate any sort of enjoyment with being inside a legacy system. And this is like, why is it? Because we are such a privileged class of humans in the world, right? So, for example, the whole pandemic came by and I mean, maybe we were disrupted a little bit because maybe we didn't go to the office and maybe some people stayed home. But we could continue to create value while most other people couldn't. And we are reasonably well paid. So, why is it that we spend most of our active professional life being not particularly happy? That's we probably are doing something rather wrong because if we don't...

Julian Wood: It sounds like it is.

Tudor Girba: ...get to be happy, right? Then what chances does anyone else have of happiness? And then again, if we go back to this idea, you know, why is it that we are the only domain in which legacy is associated with negative meaning? And when you look closer at the problem, it boils down to reading, because the problem is not that software is hard. The problem is that it's hard when you don't know what it is that you're looking at. You don't know what it is you're going to change. That's the problem. So, today, because we don't have time, people don't have time to read everything, they're going to stop when the time is up and are going to infer the rest. That inference might be true or not, but you don't know. So, all of a sudden, now you've introduced probability where you should actually be reasoning about reality, right? We shouldn't be debating whether or not the thing I know about the system is true or not. And then it gets worse because then after that, with that information, we're going to start drawing pictures. We're going to paint the system. Like, people were documenting history by, you know, painters taking time to paint certain events or persons.

But we have no idea whether that painting is real today. And that's basically the basis of decision-making in software engineering today. And then of course, it's frustrating because the result is just, you know, you just find yourself putting effort, effort, effort and effort. You know, the outcome doesn't seem to be proportional with what you put inside. So, that is frustrating. Because at the end, you end up with situations where you're kind of dancing around the fire and you're hoping to make rain happen. But the problem isn't the effort that you put in it. The problem is that the way you build the mental model is not appropriate. So, back to the name, well, we said, "Well, what if the solution, what if the answer is just by changing the medium?" Because programming is absolutely exciting. The inside of a software system can be fabulous, and can feel fabulous all the time. Bugs can feel delicious. And if only we change the way we look at it. And this is where the idea of glamorous is a name to be associated with where the toolkit comes from.

Recommended talk: Code, Immutability & the Future of Development • Pragmatic Dave Thomas & Hannes Lowette • GOTO 2023

The Future of Understanding Software

Julian Wood: Well, it certainly is a catchy term. But obviously over the past year, year and a half, two years, you know, AI has just entirely taken over the world. And I see, you know, direct parallels specifically with code I've looked at, while other people's code, even my old code where I look at, I'm using AI code assistance at the moment to explain my code. So, how do you see the sort of correlation of AI, which is also a tool and a client-side tool for explaining things and glamorous toolkits, and how sort of the AI world and this moldable development fit together?

Tudor Girba: That's a nice question. So, I think the generative AI that exists today is certainly exciting and very interesting. I don't believe the way people are using it today is the most interesting way to exploit it, though. So, when you're asking someone's opinion. So, let's say I have a question about some part of the system and I'm asking someone. And they will tell me, it's like this. Now, do I know whether this is true or not? In order to know whether this is true or not, you'll need to understand where the information came from and what bias the presentation of that information had when it got to you. So, actually, we don't want to trust people not because they shouldn't be trusted, it's just because that's not a problem in which you want to trust. It's a thing about knowing reality or not. So, rather than waiting for someone, you know, is it cold outside? It's much more efficient to just look at the thermometer and then see what the degree is, right? You would directly look at something that you can then control. And if it shows you something that is wrong, you will look at the property of the tool through which you look. And that's much more interesting. So, it's not because the problem was not supposed to be an opinion problem in the first place. Now, when we ask the AI, please summarize for me that whatever that piece of code, you're doing the same thing.

You don't know what... And the funny thing is actually ask it to summarize it twice and you'll get two different answers. Now, which one is interesting? And so that way of looking at things, looking at the output of the AI as answers is, I think, not particularly interesting. Looking on the other hand at AI as a source of questions, well, I think that's a very interesting problem. And so like asking it for how it could potentially be or what could potentially be the root cause here is interesting... You know, it's a search problem. And so finding the question is, I think, much more interesting. Now, the other thing is that any time you have something from an AI the other way to look at it, is to look at it as a hypothesis. This is something that I would like to check. Now, which is, for example, if you ask it to generate code for you, now you're back to what will be the blocker for integrating that code. That's going to be the reading problem. So, in order... You know, like, the thing is that we haven't had a writing problem for a very long time in software engineering. That's not what occupies our energy. That's not where difficulty lies. The difficulty lies in the reading problem. And the reading problem is actually a different problem. It's not an opinion. We shouldn't be treating it as an opinion. I want some other opinions about this.

That's when you're searching for alternative perspectives. But when you're looking at reality, you want to get something that is concrete. So, now where we do find the application of AI interesting in that space is creating these little tools, because every little tool is a very small, shallow problem. And AIs in the current form are particularly adept at small, shallow problems. So, for example, when you look at the picture that is being generated, you immediately can evaluate whether or not it has five fingers or has more or whether it has a foot instead of a hand kind of picture. So, you have a built-in ability to evaluate the interestingness of the proposition. And we find that with moldable development, we can split development into tiny, tiny, discrete, shallow problems, each of which can actually be the target for augmentation through potentially AI. So, that's where I see the difference. So, instead of asking the AI to give me a summary about the system in a way that I cannot scrutinize, I can't evaluate, I can't explain where the summary comes from. I'm going to ask the AI to give me a tool that I can use to apply to get the summary.

Julian Wood: I think it has been a fascinating thing. I think that in any of the past six months I've really understood the sort of agentic part of the AI and AI being able to use tools and you sort of register your tools with the system and the AI looks at the problem that you're asking in, natural language or whatever kind of thing. And I suppose with the context of your code or whatever. And then can suggest the tool that's going to be able to provide that answer. So, yeah, I can see if you have pre-existing tools in Glamorous Toolkit or the moldable development one that you've created, that the AI can suggest a tool or it can then quickly create a tool in order to solve the kind of problem. Yeah, that is also an interesting type of how these can connect together.

Tudor Girba: Or if you think, for example, let's say, refactor this code, right? One way to say, "But give me the new source code or give me the refactors that I can apply to get to the new source code." Not the same. It's not the same. It looks similar, but it's fundamentally different, the two ways, right? Then of course you want an environment that is able to host all these propositions very quickly and combine it with whatever exists already.

Julian Wood: And so just to arc and back what you were saying before, when you're saying it's a reading problem, obviously, GenAI is great at the writing problem as well for the writing problem of code, but you need to understand the problem you were even wanting to solve against or that kind of thing. Is it a reading problem or is it an understanding or a comprehension problem? Because of the reading problem, as you talked about the million lines, yeah, you can read everything that I know with memory and I'm not going to remember what I started reading at the beginning. So, is that the sort of intermediate step when you're talking about reading? It is actually comprehension and understanding, which is obviously far more complex cognitively, and hence using these tools as assistance in a way to enhance your learning and your reading and ultimately your memory as well.

Tudor Girba: Well, yes, it's not, I call it, the reading problem just to simplify it and make it a little bit more, let's say, surprising. But the goal is to get people to start talking about how they should not read code. For example, I met a company, so in my company, we are modernizing legacy systems and we get to see all sorts of companies from small ones to large ones. And so we see corporations that sometimes have thousands of systems. So, they were looking for generative AI because they wanted it, and we asked them why, and they said, "Well, we want to create faster." And we said, "Well, but you don't seem to have that problem. You've already created thousands of systems. That doesn't seem to be the most important problem you're having." So, this actually we know, the ability to create code is not the most pressing problem. The ability to understand what you have, to figure out how to change, that is a really large problem to the point in which we today create software at a super linear level...

So, the software grows super linearly, but at the same time, we are unable to recycle all systems. So, when you think about what is a recycle, it means to take a system apart and refurbish it for new purposes. But of course, before you can take it apart, you have to understand the parts. And today we are spending that energy to understand those parts by manually reading. And reading doesn't matter if you're doing speed reading, it's still capped at a constant speed, which means that you have a super linear growth and you have a recyclability function, which is basically constant. So, it doesn't work. It's not sustainable. So, we need to augment our ability to reason about what we have in order to be able to steer the systems efficiently.

Julian Wood: So, where do you sort of see the future going? Tying it slightly between the multiple things we've been talking about sort of AI code generation. Do you see the future for moldable development and Glamorous Toolkit as the sort of toolkit assistant that would be sitting next to real software developers? Or is that the real... What's your vision of the future for moldable development?

Tudor Girba: So, I think we have to distinguish between the Glamorous Toolkit as a particular artifact, and a particular environment. It's the first of its kind, so our goal with it is to show that there exists a space. To show that, this idea, the conversation about how we read code must happen because there's a tremendous amount of potential there. I think that this is one of the largest sources of value creation in the world today, not Glamorous Toolkit, but what's inside the software systems that we have today because those encode the core knowledge in any software organization. And in order to create interesting new kinds of value, if you're able to tap into that, you're able to generate even more value. And then I think it's a tremendous source that we have to control much better. But that environment is there to create a spark to start the conversation. This is not the end of the conversation. It's a very large space. And one thing I do know, you know, watching a little bit of the history of this field is that as soon as we decide as a field that a subject of conversation is interesting, in a reasonably short amount of time, we can innovate in that space dramatically.

So, for example, everybody talks about, you know, for example, continuous delivery. Now, if you look at which ones, what were the tools at the beginning, that's not particularly relevant, right? What's interesting is the fundamental ideas that you want to embody afterwards in environments. Now, where do I think this should go? Yes, I do believe that there is no other way to make software inhabitable for humans, other than augmenting our brain to reason about the inside of the system. That's the only way. There's no other possibility. And so this can only happen through tools. Now, these interesting things, if you go back to our origins of personal computing, personal computing was always meant to be personal. It wasn't meant to be a thing that is used in exactly the same way by billions of people. That's not what personal computing meant. But now somehow we got somewhere in history, a little bit of a wrong turn. And now we've gotten to the point in which even people that are paid to create software, cannot even imagine creating the software that makes it interesting for themselves. So, the potential is tremendous. The opportunity already exists. We just have to make this a subject of conversation. And I'm quite convinced that we in a reasonably short amount of time will be quite surprised at where environments could be.

Julian Wood: Okay. Just to pick up on the one term you used of software being habitable. I love that term, actually, because it shows that you're very much invested in the places where you habituate, or where you live, or where you work. And you actually feel as though you're sort of physically inside something. And I can have that mental model of physically mentally being inside your code to be able to understand it and looking around or walking around a house, walking around an office or something and actually visualizing the various bits and pieces that put together the structure in the same way that you can put together classes, methods, objects, and software code. And I can see the analogy of walking around and having this visualization in a building, having the same visualization in the code. So, yeah, that was a bit of spark, my mental neurons to think about code being habitable because being inside your code, I think has good value.

Tudor Girba: So, just maybe as a way to end habitability actually was coined by Richard Gabriel in 1995. He wrote a book, "Patterns of Software." And I found it at the time the idea was different, it was about piecemeal evolution. And you have to make the code, for example, readable, which we still talk about that idea today, which is, again, it's an interesting idea, but it's a tiny micro-optimization because at the end, we have to change, not to assume that we have to read it, but if we complement that with this idea that we can control the interface, then the whole idea of habitability gets a whole new dimension and it can be many times multiplied.

Julian Wood: Definitely. And it's only an internet scale, a child scale, and a distributed software scale. This problem/opportunity is only getting bigger and bigger. Tudor, thanks so much for spending time with us today. I just know that there's so much more I need to dive into this. Moldable development seems absolutely fascinating with a fantastic current iteration of a tool called Glamorous Toolkit. I can understand that the future is all about having tools, helping us understand our software. So, thanks so much for all spending time with us today on "GOTO Unscripted." Tudor, thank you very much.

Tudor Girba: Thank you.