Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Making Software Habitable with Tudor Girba
0 Plays2 seconds ago
Tudor Girba is the CEO of feenk, a company focused on modernizing legacy systems. They do that through Moldable Development, a way of programming through custom tools. They build Glamorous Toolkit, a free and open-source moldable development environment, to show how working through thousands of custom tools per system can be practical.
Sponsored by CodeCrafters - discount link
LINKS
- Tudor's LinkedIn
- feenk
- Glamorous Toolkit
- Moldable Development
- Rising Strong by Brené Brown
- Global Village by Marshall McLuhan
- Above the Line, Below the Line by David Woods and Richard Cook
HOSTS
- Andrea Goulet LinkedIn | andreagoulet.com
- Ray Myers LinkedIn | Craft vs Cruft on YouTube
ABOUT EMPATHY IN TECH
Empathy in Tech is on a mission to accelerate the responsible adoption of empathy in the tech industry by:
- Closing the empathy skills gap by treating empathy as a technical skill.
- Teaching technical empathy through accessible, affordable, actionable training.
- Building community and breaking down harmful stereotypes and tropes.
- Promoting technical empathy for ethics, equity, and social justice.
Learn more at empathyintech.com
Recommended
Transcript
Why Software Systems Should Suit Humans
00:00:00
Speaker
Given that we spend as as engineers, and given that we spend most of our active life inside software systems, it should follow that it would be a good idea to make those software systems suitable for human inhabitants.
Introduction to Empathy in Tech
00:00:14
Speaker
Welcome to Empathy in Tech, where we explore the deeply technical side of empathy. And the critical need for empathy in technology. I'm Andrea Goulet.
00:00:24
Speaker
And I'm Ray Myers.
Guest Introduction: Tudor Gerba and Fink
00:00:26
Speaker
Today on the show, we have Tudor Gerba. Tudor is the CEO of Fink, F-E-E-N-K, a company focused on modernizing legacy systems. They do that through moldable development, a way of programming through custom tools, and they build glamorous toolkit, a free and open source moldable development environment to show how working through thousands of custom tools per system
00:00:56
Speaker
Yay. Okay. So I want to dive in because in the call portion, when we were kind of getting to know each other and prepping for the podcast, you told us that you the name of your company has a very special meaning. And I would love for you to tell the listeners how you came up with the name of your company, which is Think. So, and it's spelled F-E-E-N-K.
Redefining Legacy Systems
00:01:18
Speaker
Yeah. It's called F-Think and it comes from feel and think. And, um, the reason for this is.
00:01:27
Speaker
related to one thing that I i noticed in when talking and interacting with developers that were working, for example, with legacy systems. So I was asking quite a number of them, so a few thousand. um yes I asked them if um if they love working with legacy systems.
00:01:48
Speaker
And that never crossed anyone's mind, you know, associating that feeling with legacy systems. And it got me thinking um because, well, given that we spend most of our time inside legacy systems. And just to quickly define legacy systems for people who may not be familiar with the term, because it's different than the way the rest of the world uses the word legacy. How do you define legacy code?
00:02:15
Speaker
Well, I i kind of i just ask i ask people to define legacy. I think that legacy ah should be associated with something that is highly positive and value create ah something that creates value. um And it should definitely be something that is enjoyed. Typically, the word is used to like talk about, eww, it's stuff that's hard.
Incorporating Feelings in Software Development
00:02:36
Speaker
it's I don't want to touch it.
00:02:38
Speaker
And it's frustrating and it's annoying, it's hard. yeah and um And so ah the the problem there, if we dig a little deeper, um is that we spend a lot of time in in our industry ah concerned with how we think.
00:02:59
Speaker
but we do not really consider how we feel. And I think that's a mistake because the way we feel is as important as the way we think. And that's where the name of the company came from. And so I think we, on the one hand, we solve hard problems, typically related to legacy systems. On the other hand, we research new means by which humans can actually relate to the inside of softer systems. So today, softer systems are mostly considered to be black boxes. And even people working on them find it difficult to understand what the system does. And um given that we spend um so much energy building those systems and even more energy using the systems, um and given that we're reshaping quite a large part of our life
00:03:57
Speaker
on top of software systems, I think it's not appropriate to not understand how the box works. Yeah.
Tudor's Journey into Legacy Systems
00:04:06
Speaker
So when did you decide that you were going to be interested in legacy code, that that was going to be a primary focus ah of your career and and and tell us a little bit about that?
00:04:21
Speaker
Okay. Well, that goes a little bit back, um, about 23 years ago or so. Um, that's when, uh, I, uh, got, I was, uh, I graduated from university and then started to look into, so started working my first job.
00:04:42
Speaker
And then I joined the company, which was local, where I was but i did my university. And there were pretty good engineers there. And then we're working on a legacy system. And and they were describing how um there were these good old times. And I asked them, so what does but does what does good old time mean? Well, there used to be a time when we were doing what we wanted with the system, they said.
00:05:10
Speaker
And then I said, well, so how is it now? i sound like like kind And it sounded that they were actually doing what the system wanted. And um they got me thinking at that time. And that's when I started to ah got more interested in this field. Plus, I had a ah very good colleague. Well, at the time, he was a university assistant. is' He's now a professor university professor. He's called Radhu Marinescu. And he got me, also,
00:05:38
Speaker
um pointed to the towards research and in academia.
Balancing Emotions and Logic in Development
00:05:44
Speaker
And then I did my PhD in the field and then postdoc in the field and then um eventually got to coin the idea that today led to multiple development about 15 years ago.
00:05:59
Speaker
When you talk about shifting focus to not just how we think, but how we feel, what does that look like? What would be an example of we weren't taking appropriate action on the way like our legacy system makes us feel? And then you you do you apply this new perspective. what What changes? What does that look like? Maybe maybe let me give you an example.
00:06:26
Speaker
um So not too long ago, we worked with them we work with the company that tried to optimize a data pipeline. And um it was an important data pipeline for them. The main marketing offering ah was going through that pipeline. so a pipeline And they ah they wanted to optimize the performance of it. So going from basically having the data until the moment they were ah Be able to send an offer it would take about one day and they wanted it to be about one hour so um and they knew about that and then they decided to to work on doing this and CIO knew about this.
Challenges in System Understanding
00:07:11
Speaker
So it was a big thing um All the way to the board. So there was a CIO directive an initiative people working on it budgets allocated three years later and
00:07:23
Speaker
It took exactly one day to go from having the data until the offer was being sent out. And that's frustrating. Another question is, well, why is it? And well, it turns out that before you can do something with the system, you have to see the system.
00:07:48
Speaker
you have to have a mental model about what the system does, where the problem comes from, how you can possibly affect it. And ah if you don't see it, then you start building myths about the system, you construct beliefs about the system. And then of course, those beliefs will might not match reality. And if you continue you know behaving or acting on top of those beliefs, then You end up, and the metaphor that I like to use is dancing around the fire to make rain happen.
Concept of Lenses in Understanding Software
00:08:22
Speaker
And, um you know, like you you put the energy in, um but it's really frustrating because there's no, this doesn't seem to be a correlation between the effort that you put in and the effect that you're actually looking for. And the reason for that isn't the lack of will or the lack of energy. It's the fact that you don't understand cause and effect.
00:08:45
Speaker
And that's the core problem that um that we have in and software engineering today. People don't see the system. um So they believe they see it, but they really don't. And so coming back to our story, um the way we help people see the system is we we basically build a lens or set of lenses through which they can look and see.
00:09:12
Speaker
So today people gather information about systems mainly by reading. So developers spend most of their time um just going through the system trying to figure it out. And the way they extract information to make the choice, make the decision is by manually reading usually code or some sort of textual artifacts. And that's very, that's um that's that's slow, it doesn't scale and it's very inaccurate.
00:09:42
Speaker
So the consequence is nobody has the time to read the whole thing. And as a consequence, um most of the information is actually inferred. And this one is easily leads to beliefs that are not real. And so the way to solve that is, or the way we address it, is by creating tools that basically summarize the system for us. So give us these tools, they give us perspectives that we can reason about much faster than by reading. highly these These views are highly specific for the question we have. And through this, we can turn through questions and answers many times faster than if we would manually gather the information. And just by doing that, nothing else, just by making this cycle. And today, we call ah we talk about the mean time to question and the mean time to answer.
00:10:40
Speaker
um
Adapting to System Changes Over Time
00:10:41
Speaker
If we decrease these two, um we simply enable people to make much, much better decisions. And then at the end, you enjoy being in the middle of a system that you can actually affect.
00:10:54
Speaker
Yeah, it makes me think what you're describing. There's in Brene Brown's book, Rising Strong, she has a quote of, in the absence of data, we will always make up stories. And I think that's kind of what I'm hearing here is like ah we are then having a discussion. And I think we see this even outside of software, you know, in in China, just the general population is I believe this thing because I've got my set of information that I have from my lived experience and all of that.
00:11:23
Speaker
You have your set of information, but then like you know a system really is when we're connected. but So what's that thing in common that then we're kind of triangulating our perspective against that we can then debate? Because what I like about this is that when you have the data about the system, then you transform the argument from being a personal thing to then being like, OK, we're going to work on the system together. And then you have a goal in which you're working on together. And I think that's where I've seen real progress happen. Yeah, that's I really like that perspective. And um yeah, that's pretty much it. um so people have So we have two two kinds of problems. Yes, indeed. One, having the data. And yes, we do see these other problems in other places. The the one thing about software, though, is that the amount of complications
00:12:15
Speaker
that accumulate in even a reasonably small scale system. So let's say one, two million lines of code, for example. um So with just ah one, two handfuls of day of people, the amount of complication that we can create there is is is many times larger than in other places at the same scale. So we literally, in a system, we it's hard to enumerate things on your hands. and So you can't you cannot have them in your head, because there's just too many things.
00:12:44
Speaker
So, and that that makes a big difference ah between the situation and something else. Also,
From Beliefs to Reality: Accurate System Representation
00:12:51
Speaker
the other thing about this system is that it changes all the time. And so things that i might I might have known yesterday might actually be an impediment today because maybe the system has changed. Maybe slightly, maybe not so slightly. But yeah like if i if I'm not refreshing my perspective. Maybe there was a new virus that happened to impact the entire world and then you had to shut down. but you know For example. But it doesn't have to be that big either. b
00:13:20
Speaker
You know maybe somebody got really sick on your team and they were the keeper of knowledge for a lot of different things but now they're not available or they won the lottery if you want a more positive framing. around that but yeah but but but But also in the system, so this is on but on the human level, but on the system, for example, it could be, oh, we drew some some architecture on a whiteboard. We agreed to that. But some commits, they slightly go a little bit off track. And you don't notice it at the beginning. It's just a a little bit of erosion here and there. ah right But then ah you don't notice it, let's say, for two years in a row. And then all of a sudden, you're in a different place, and you still believe that you're
00:14:00
Speaker
you're on the diagram on the on the whiteboard. um and And that's where things start to go less well, essentially, right? And now, and so the issue with the diagram on the whiteboard is, so the diagram is really well-intended um because it's a, well, we want to externalize the model that we have about the system so we can start talking, so we can negotiate between ourselves.
00:14:22
Speaker
but not not me against you, but both of us against the thing that is on the wall, which then leads to collaboration. And that's healthy. The problem, though, is that we want the thing on the wall to represent the thing in the system. Because if those two are not the same, then all of a sudden, um that's where the frustration comes into play. Yeah, now its now it could be worse than useless. It could be just misleading you. It is.
00:14:52
Speaker
I recently got pointed to to early articles about photography from 1900. And so i I read a few of those. And it's really interesting because that that that was basically the period where people went from painting as a way to document reality to taking pictures as a way to document reality. So in in the painting world, essentially, we don't know what reality really was.
00:15:22
Speaker
Um, we have some, so for example, you know, especially if you go to, uh, you know, 1700, 1800, you know, people like all these, um, Kings on horses and all horses look the same and then people kind of look the same too. So you don't exactly know what, what's reality and what was added in. And then, um, the shift towards the photo photography as a means to document was, was quite important because all of a sudden we can, we could start to, um, we eliminated a source of uncertainty that was In fact, not needed. And interesting enough, people that were painting or focused on painting reality, all of a sudden, about in the same period of time, shifted towards um painting ideas or painting as ah as a means to express a wish or or a perspective. And that's kind of it's that's very different. Now, when we come back to if we come back to the diagram on the wall,
00:16:22
Speaker
or on the whiteboard. um That's actually, if we have done it manually, it's it's like a painting. So we're very much, um because people draw their systems manually, they basically document mostly their belief about the system rather than the system itself. So we don't know exactly when you look at a picture like that, what's real and what's not.
Custom Tools for Context-Specific Solutions
00:16:47
Speaker
And that's an unnecessary variable in an engineering setting.
00:16:52
Speaker
um So the alternative is to replace those paintings with photography. And then, of course, in our term, in our world, um it they would become visualizations, views, or other forms, views into the system. um that That basically depict the system as it is.
00:17:14
Speaker
I really like that metaphor of moving from painting to photography because I think you can even extend it a little bit. I'm a total nerd and watch all these different documentaries and stuff, but I remember watching one about art history and kind of the evolution of portraiture. and ah In the Regency period, so you know in the 1800s, what happened was that the demand for portraiture started to go up.
00:17:41
Speaker
And so you ended up having different artists who would focus on different areas of the portrait so like one person would paint the background and then now I get handed off to somebody who then paints the you know ah gown or whatever and other people would do the still life and then the person.
00:17:59
Speaker
when they When people wanted to pose for portraits, they didn't stand and pose for the whole thing. They just had something that was already done and then they the kind of master would then paint the face on top of it. and I think that's so similar to how I see software teams nowadays because a lot of it is kind of this past the potato. kind of thing and we're all working individually on our own like elements and then eventually hopefully it all comes together. um But i I like where I think the challenge comes in because that's very much a production line kind of challenge and so we would call that a complicated system. But in software that doesn't work because everything's changing and you know we have to adapt but I like that idea of if we can take photography
00:18:50
Speaker
And then just like, it's quick, it's accurate, right? We know it's not, ah you know, subjective. And, you know, that gives us something that we're able to relate to a little bit better.
00:19:04
Speaker
Hi, Ray here, and I'd like to take a quick moment to tell you about Codecrafters. In my career, I've helped a lot of people get to the next level of software developers, and whether you're just starting out or looking to branch out into new challenges, one theme that comes up again and again and again is that people just don't have the right project, and they bounce from tutorial to tutorial. They don't get to integrate what they've learned into a real context. And that's why I'm excited about the CodeCrafters curriculum, which is based on building complete applications from the ground up, step-by-step with choice of language. I'd like to get weird next week. Maybe I'll build my own Kafka in Gleam. You can find a discount link for
00:19:59
Speaker
I would like to jump on that idea that software is constantly changing. Is that good necessarily? Should our software be changing as much as it is? And we could tie that to an idea that you've put forward as well about how software changed over time. Software environmentalism. What what is that? And why why do you suggest thinking about things in that way?
00:20:29
Speaker
Yeah, so whether is it good that the software changes all the time, um it's it's just a fact. And the reason it changes all the time is because the environment changes all the time. And that's the interesting thing about software is that it is highly contextual. So as soon as the the context changes a little bit, um then for software to remain relevant, it has to change too.
00:20:51
Speaker
And because we are targeting smaller and smaller contexts, um then this this need of changing is actually preventing. So it's just a fact. So the so then we can say, well, ah one way to look and think of this would be to say, well, we have a plan. We have to make this a softer stick with a plan. That didn't work, um really. so And the same thing doesn't work with this idea that you know a system conforms to some sort of architecture.
00:21:20
Speaker
um because it's the other way around. um The architecture is something that emerges out of the system in its current form. so um So instead of being so focused on trying to make the plan happen, you can also simply ah recognize or invest in your ability to see the system as it is now, and and basically see be able to project to the high-level perspective the way you want it so that you can identify, oh, there's a delta between what I wish and what the and what the direction is. And then that delta is, um can you can interpret it in at least two ways. So one would be to say, well, the system is wrong. And the other one would say, well, what am I missing?
00:22:02
Speaker
And both are interesting. It's very interesting. and Because often, you know, value gets created serendipitously, right? You just notice something. So why is this happening? And then you start to understand and the phenomena and news. And then ah it potentially leads to a new perspective that you missed before.
Software Environmentalism and Sustainability
00:22:22
Speaker
um So ah this again, a value, this this this then opens up and the possibility to create value bottom up.
00:22:31
Speaker
um So if you think about, let's do a a little bit, open an even larger bracket now. So if you think about something like DevOps or and continuous delivery, um that um was a very large change. But in fact, at the core is like really like the geekiest possible thing. like it's It's essentially focusing on how how a commit moves from my you know from the versioning system to into production. Like, who cares? ah But it turns out that everybody cares. It's it's like to did the the tiniest detail, and yet it changed everything. But how did it change everything? Well, it changed everything. and So of course, on the one hand, you know it can deploy faster. So you go from one time per year to and many times per day.
00:23:25
Speaker
um But if you don't change anything else from this from the state where you were when you deploy one time per year and the state where you were when you deployed 10 times per day, the um the the difference is marginal.
00:23:40
Speaker
If on the other hand, so if nothing changes, only if the only this is the only thing that changes, there's not going to be a very large visible difference. If on the other hand, you now say, well, all of a sudden, maybe I shouldn't be churning features or you know, believing that certain things are meaningful and work on those, but rather I'm going to put them into the world and then observe the world and then learn about my system.
00:24:10
Speaker
um then I'm in a different place, right? but But it requires that shift. And without that shift, you don't see a lot. There's not a lot of benefits. So there is a really interesting new change that basically opens up a space, but you can only you only exploit that space if you change the way you think um about how you create value.
00:24:34
Speaker
Now, what's interesting about the the reason I am interested in continuous delivery is because it is it's it's um this learning you know learning about your system from the way the immediate the environment reacts to it is I call this one an outside in kind of conversation. um So I learn about my system from the outside. um But there are on the other hand, there are risks and opportunities that are exclusively visible on the inside the system.
00:25:01
Speaker
And the ability to orchestrate a view into the system, so create these lenses so which we can see. And it can be anything. It can be architecture. It can be domain. It can be you know the way the system runs and so on. um If I am able to see my system the way I want any time I want at as low cost as possible, um then I have the opportunity to create new kinds of value that which comes only from the exclusive vantage point that I have when I'm inside the system. And then, of course, again, just like with Netlops, if this is the only thing we change, the difference is going to be marginal, not really interesting. But but if if, on the other hand, I'm now going to be focused on, oh, how many interesting questions do I have about my system?
00:25:51
Speaker
hu And so, and when I go from, let's ask ah one large question in a rather vague about the system per quarter to what happens when I'm asking dozens of questions per person per day. Yeah. I'm in a different world. And so,
00:26:11
Speaker
um And ah that's how I think we should be dealing with change. Change is not something to be you know to be scared of. If you're actually able to form an opinion about what you see in front of you all the time. like The world around you changes all the time. And you have no problem like with you know crossing the street and all the cars. They don't go conforming. They don't conform to a plan. And you have no problem adapting to that.
00:26:35
Speaker
taking a train and so on. So you can deal with those problems quite comfortably. This is not a problem. The only problem comes from your ability to see. So if you are not able to perceive what happens around you and just you know cars bumping onto you ah just you know when you don't expect, then that's frustrating. But if you see, if you're able to perceive, then all of a sudden, it's not it's not a real big issue. So this is how I think about change.
00:27:04
Speaker
Yeah, I was doing some research recently on you know complex systems and like how do we measure them? How do we know if they're effective? and um yeah I came up across the term of an ergodic system, which is one where it's complex, there's a lot of interrelated parts, it has to adapt to its environment, but it's not ah highly sensitive to its initial conditions.
00:27:32
Speaker
so that Sometimes it's the difference between a complex and a chaotic system. But when we think about an ergodic system, one of the really cool things about it is that we can generalize the effectiveness of it. If we look at, you know, we can typically find one or two like trends that we can look at to overall measure the health of the system. And there's a lot of different ways that like by measuring smaller things in the system, we can get a better sense of what that is. But you know for me, I think when it's both software systems and social systems,
00:28:08
Speaker
like I can gauge the health of the system by recognizing how quickly is somebody able to identify a problem and deploy a solution. Then it's like, okay, now we've got a bunch of things to optimize. But then that way, even if you don't have kind of the math behind it, you know your ah Your work is really giving us kind of a way to kind of get a sense of how that is happening.
Importance of Context-Specific Metrics
00:28:40
Speaker
Let's say I'm a product owner or something. I might think that you know deploying once a year is no problem.
00:28:48
Speaker
right or you know a CEO, and I don't necessarily see the potential of how something could be better. um Yeah, but I think when we can wrap it around something that people know is like, yeah, that's the goal that we all want. but We all want to be able to identify problems and figure out what to do about it and get those problems to you know, life as soon as possible, whether or not that's through code or through, you know, innovation in some other form. But yeah, that was something like, as you were talking about, you know, kind of measuring the system. And one of your things too, is that the metrics that we typically use, this was your area of research, right? Where like a lot of the metrics that we use to measure the effectiveness of of a software system often fall short. Yeah. And they fall short because they are too generic.
00:29:41
Speaker
m Again, one of the problems or one of the characteristics of software systems is they are highly specific, highly, highly contextual. So context trumps anything else. So um then of course we wanted to have, oh, you know, how do I understand, is this a good system? Is it a bad system? Where are the bad parts of of my of my code? And those questions are very all luring because, you know, you ask them, you answer them once and then you can deploy them everywhere. So that's kind of,
00:30:12
Speaker
yeah It's very, very tempting to to do it that way. And I did i did spend quite a bit of energy um researching that' that that kind of track. I'm very much convinced that it's it's a dead end ah today because I have seen the alternative. And the alternative is to say, well, what if I don't need scale to solve problems? What if I can actually solve the problem of in context and start from the context?
00:30:39
Speaker
And that's where that's is this is the whole idea behind multiple development, which is a way of programming through custom tools, which means we're going to say we're going to take any question we have about the system. And I'm talking about from the largest problem that I have, like how do I migrate my, I don't know, system to somewhere else, ah to the tiniest bug um you know a developer might have ah for half an hour.
00:31:04
Speaker
um Any of these, we will tackle through custom tools. We're just going to refuse. We're going to just want to be able to build a tool that makes the problem apparent, so apparent that the solution becomes obvious. um And that's it. And so um from that point of view, i don't want I don't need the things to be reusable, not in the sense that I have a a single metric.
00:31:32
Speaker
that we're gonna deploy pretty much like how ah people don't, we don't have a single set of tests that we all gonna use on all our systems. No, no, instead we're gonna build a test. ah Every single test we're gonna run against our system pretty much. We're gonna write them in the context of developing the system. And it's kind of interesting, right? So the the notion of the test is reused, the framework in which we are going to express the test is going to be reused, but not the specific thing. Because the specific test, which is an analysis tool, it's a way to give us some sort of summary about the system. A specific test gives us context. So when we are writing an assertion, something like make the test fail or pass, we're actually encoding the contextual value that we want to stop about.
00:32:30
Speaker
So this is the reason why even if you have a 10,000 or 100,000 failures, if one test fails, we stop the whole production and we don't go forward. Why? Because every one of those encodes some sort of value that is contextual.
00:32:46
Speaker
And that's important. Now, we can do this. like Tests are really great, except that they only decompose the system through a very particular point of view, which is functionality.
Reducing Costs of Custom Tool Development
00:32:55
Speaker
And typically, external, something that is visible externally. um But there are many other ways, many other perspectives about the system. And they're not easily or nicely decomposable you know from a functional perspective. So if I weren't, for example, taking a look at architecture, um it's not something that a functional perspective would give me an interesting um again an interesting insight into. so ah so But we can apply the same principle of saying, well, what if I'm going to build something that's highly contextual? And it turns out that there is a science behind that. There is a science behind thinking about how do you create kinds of tools like this? What kind of languages do you need to express such tools? How expressive can those tools be? And so on. um And there is a science of bringing those data costs to almost zero.
00:33:42
Speaker
um or Ideally, our goal is to bring it to be to to build to bring the cost of the custom tool to be so low as to advertise it on the first use.
00:33:55
Speaker
I don't need to use it the second time. so If I have to use the tools twice, in order to like if the cost of the tool, building the tool requires me to solve two problems,
00:34:07
Speaker
with that tool, um I have to think before I have the first problem, when I have the first problem, I have to think, will there be a second one? Or what's the chances that I'll have the second one? Because only then will I build the tool. But if now the cost of building the tool is, and using the tool is actually cheaper than not building the tool on the first use, then I don't have to think about that. And in that situation, building the tool becomes the default.
00:34:37
Speaker
So our target was how is it possible to add value, let's say within end a few minutes? Just build a little training increment to whatever the tool, whatever we understand as a tool.
00:34:50
Speaker
and have that one build me enough value so that I can spend more, a few more minutes to build the next increment and so on. And and it turns out that is actually possible. And it also turns out that you can approach a very large, a very large set of problems. And I'm talking like we have looked at thousands of problems and we have built tens of thousands of tools over the last decade or so.
00:35:19
Speaker
um And we approach all of any problem that we've ever found that we ever faced for the last decade just through the same through the same approach. So the approach is reusable. It turns out that it's possible to build some kind of like a platform or environment that is reusable, but the actual tools ah to be reusable, that's not interesting at all. And this leads us to in a different world.
00:35:44
Speaker
I'm thinking that this it kind of extends your photography metaphor that we went kind of wrapping back to it. like I know that um yeah my family recently stumbled on some old photographs of my great grandmother. like This was in the late 1800s. My family is big and like so um but the um They invested in photography and they were farmers. right so It wasn't like they had a lot of money, but it was one of these like they took like it was a really big deal for them.
00:36:18
Speaker
to sit for a photography session for the whole family. And it was one of these ideas like, we're going to reuse this, but it's going to hang on the wall. But you can't really reuse that unless you have the negative. But now I'm thinking like the cost of photography, especially as we're moving into digital photography, it's so cheap. Like, I mean, I can...
00:36:36
Speaker
I can take pictures all day long on my iPhone and it's just like, whatever. And then if I want to remix it and put it into a collage, I'll do that. And so it's like, I can just reuse it over and over again because it's really easy. So I no longer think about taking a single picture as the investment. Is that kind of like metaphorically what you're thinking of?
00:36:57
Speaker
and Actually, I wanted did to come back exactly to that point ah before we went into the into the other direction, because I think this is really ah right ah right on the money here. So it's not enough to replace painting with photograph photography if you still have to think too much about how the the the photograph is going to be. If you have to spend too much energy doing that, only you will only do it in some extraordinary situations.
00:37:23
Speaker
Or if there's only a limited amount, people who have the technical capacity and the equipment, right? Exactly. Yes. And so if, on the other hand, if it goes below a certain threshold, ah if if the cost of the photography goes below below a certain ah threshold, then all of a sudden you're in a completely different world, which you would say, well, it's like we're still photographs, but it's we it changes the way you communicate.
00:37:50
Speaker
And and that that is interesting. And this is where we wanted it to say, so for this is why we're saying, you know, when we say, oh, custom tools, it's not just custom tools, it's thousands of custom tools per system. Like it's so ubiquitous to create these custom tools.
00:38:07
Speaker
Just like you have now thousands of pictures per, I don't know, maybe a month or so, um it it's possible to be to live in that world. And it there's ah it just enables a different way of communicating. ah but We can discuss whether there's a good thing or a bad thing but in the in the case of photography. But when it comes to understanding reality, um it turns out to be really, really interesting.
How Tools Shape Digital Understanding
00:38:31
Speaker
um that that getting the getting the cost of a picture about our system to to to be ah less than a certain threshold. And this is why we get into that world. But coming back a little bit to the other question that Ray asked, which is, how is that related to what I call software environmentalism?
00:38:55
Speaker
so
00:38:57
Speaker
Today, the body of software grows super linearly, if you look year over year. um On the other hand, we are unable to recycle all systems. So from this perspective, we behave no differently from the plastic industry. And it's not sustainable. And given co given the given the fact that we affect everything with software,
00:39:24
Speaker
The way I look at it is is it is a problem of as large as the physical world um environmentalism problem. So I call that one softer environmentalism. Now, what does what does it have to do with everything we talked about until now? Well, so to recycle the system means to take it apart and refurbish it for new purposes.
00:39:52
Speaker
But before you can take a system apart, you first have to understand the parts. Now, today, the way we understand the parts is by manually reading through systems.
00:40:06
Speaker
And in fact, it turns out that we don't understand those parts. And the reason why we are unable to recycle or we recycle it so slowly ah is because it's the bottleneck is in how we how we go about understanding our systems. And so the them the alternative, I believe, is that we need a recyclability function that matches the growth of the system.
00:40:33
Speaker
And the only way to do it is, I mean, one way would be to say, well, everybody should take a speed reading and course. Right. But then, we might get into, you know, this quote where you said, well, I read War and Peace in one hour and it's about Russia. Yeah, that's a really good point. Right. so So that's, that's one way to go about it. And the alternative is to say, well, what if, what if the way we can reason about the system shouldn't depend on the system size at all? And that becomes a tooling issue.
00:41:04
Speaker
And so this idea of the lens, like the the thing through which I look at the system becomes kind of fundamental. And in fact, it is fundamental because in the you know in the physical world, everything has an innate shape. There is a way to look at anything around me and touch it, for example, right? So there is some sort of, you know, it's hard to escape the form in which the the things have. Now, for the longest time, what we have depicted about the real world actually matched that shape. It was only about 500 years ago, 400 something years ago,
00:41:45
Speaker
that we started to put two axes, you know, x and y, and start depicting something that is abstract, something that it is about reality, but it doesn't match that shape. Because even in reality, there are multiple ways to look at reality. There's not just one way. Now, in the digital world, there is not even an innate shape.
00:42:08
Speaker
We cannot touch anything. We cannot perceive anything inside the system except through a tool. Therefore, this makes the tool fundamental. And we should 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. And we know this from Marshall McLuhan and you know from 56 years ago, which was telling us exactly this, that in this new world,
00:42:38
Speaker
the medium becomes the message and the tools end up to influence it the way you're going to think.
Shift in Programming Perspectives
00:42:43
Speaker
And it's we very much see it live in ah in the software world. Because you know there's a very interesting correlation between what developers do, read, and the shape of the tool that they are typically exposed to on a daily basis. So if you take two screenshots of two developers, two developer screens, one working on a banking system, one working in automotive,
00:43:08
Speaker
and you take two screenshots and you then afterwards put them like one meter ah you know away from you. You can't tell which is which because they're literally going to look pretty much the same. and Those tools are very rigid. The things this editor, this giant thing and just some text change there and some index on the left hand side and maybe if you're lucky a little bit of ah some sort of support here and there.
00:43:34
Speaker
it's It's a very, very rigid way to look through. And what do people do when they see these blocks of text? It's kind of interesting to observe that they start reading. But on the other hand, you give the same people a database. And the database tool um has a big giant text you know query box at the top.
00:43:56
Speaker
So what do people do? Well, they turn out that they are not reading the database. They're going to write a query. That's the first thing they do. And it's really interesting to see how the characteristics of the tool correlate with the behavior. Now, where is the query box over my software code? Why is there no query box? So that's what that's what you're creating ah that with moldable development.
00:44:22
Speaker
Yeah, so first of all, you want a query box. But then you look at the questions, what else? right What other things should we have in there? We should be very careful with the characteristics of these tools, because they really have tremendous power of the way over the way we think. um So you know for example, if you look into the data science space,
00:44:45
Speaker
So now people have shifted from rigid tools. yeahp I don't know if any of you remember the world, the age of dashboards um and you know like rigid industry wide standardized dashboards and so on, which were the craze of you a while back. right And nobody's doing that anymore. Instead, what people say, well, put the put the data scientists really, really close to the business so that they can churn through ideas very quickly.
00:45:12
Speaker
And it turns out that that works. It works to start from the question, build the view that is specifically targeted to that question, and then you know generate value out of this. Yeah, the same idea, but for everything else. It's not just for data that comes from somewhere. Everything around our systems is just data. And we can actually look at it like this. And the economics, we already know, they really work.
00:45:37
Speaker
And it's it changes it this this perspective would then change the nature of programming itself.
Chaos Engineering and System Resilience
00:45:44
Speaker
In my work, I can actually validate a lot of this kind of unorthodox perspective that you've got about the the primacy, the importance of increasing you know our ability to perceive the system and and ask new questions. I ah do something called chaos engineering as part of my job.
00:46:04
Speaker
And that is for anyone who doesn't know, ah deliberately causing ah small outages in order to study them. And ah pursuing this, like what I learned very quickly was that actually the value of doing that is a little bit misunderstood.
00:46:21
Speaker
If I could simply tell people that I was going to do a chaos experiment and I needed them to plan it. And then we just did that, that planning. And then we never ran the experiment. I would believe actually that's most of the value has taken place because when you tell people you're going to break the system on purpose, they're now very motivated to get together and exchange information. You walk out of there with the sum total. of everyone's knowledge about how the system fails is now in most of those people's heads. You've you've spread it around. you know you've you've You've enriched your your internal model. And then sometimes you actually learn something when you actually do it, but most of the learning happened just through that exercise. And I, exaggerating slightly, you'd say like, I might not even have to do the actual ah breaking of it if I could just convince them that I had so that next time I come around, they need to pay attention.
Personal Computing: An Extension of Individual Needs
00:47:16
Speaker
um And there's some foundation on this in resilience engineering. There's a great article, a link in the show notes by Dr. Richard Cook, who's a very influential safety researcher. um And he, it's called Above the Line, Below the Line. The line is called the line of representation. ah Below the line is what people normally call the system. It is the the technical system. Above the line is all of us. I like that.
00:47:45
Speaker
The line itself, right it is impenetrable. We will never see a database table in its natural form. We will never see a message queue. We will never see any of the stuff that we talk about that's in the architecture diagram that's in our our system. We can only interact with things that are at the line of representation, like our monitoring, like ah various other things.
00:48:08
Speaker
and so um This, you know, very much emphasizes the primacy of actually bringing resilience in the systems all about the mental models of the people above the line and whether that has any resemblance with what is actually going on. And so you're trying to optimize for creating new representations so on the fly so that those people can have better mental models. I have found, like, this is a really valuable idea. I found it incredibly difficult to actually sell. Like,
00:48:38
Speaker
to convince people how important enriching people's understanding is. Now, your solution to that seems to be, let's make it so cheap that even if you're only half convinced, you might do it anyway. But I just wonder if you have any other anecdote um about like, ah how how do you know that people are ready to hear the message of this is what you actually need to do? Is it just a matter of, well, we've been trying to get the runtime down for an hour and we've tried everything but this, so we might as well.
00:49:08
Speaker
this is This is such a cool perspective. I really love it. um So let me see. where do i is I have to narrow my answer down because you just opened up so many things that I wish I would have the time. We would have the time to talk about. but So how do we know? How do we convince people to to look at this? Because you're right. right People are not um they they arere not red They are not willing to accept the idea that they should be building their own custom tools. Now, here's the crazy thing. it's really It's really crazy. If you go back to the 70s when personal computing was created, the reason they call it personal computing was because it was was meant to be personal, not not cookie cutter things, not things that were mass produced and everybody has the same. um and You just mix and match some of those boxes. No, it was the whole idea was that it should be an extension of you.
Empathy's Role in Technology Development
00:50:01
Speaker
um And then at some point, we got like in a terrible turn of events. Somehow we got, you know, the industry educated everybody ah to this idea that software has to be provided to you by somebody. To the point in which today people paid to create software do do not even conceive of creating their own software.
00:50:27
Speaker
So this is is so broken, but it has no bearing in reality. It's just it's ah it's a myth. it's doesn't It doesn't exist. Now, of course, yes, I understand. this is ah What we are proposing here is it's a very it's a complete departure from what the trend ah the trend that exists today. um it's not you know But on the other hand, it's it's much closer to what existed 50 years ago when, yeah as I said, the original research happened.
00:50:56
Speaker
First of all, the way to convince people is to show it. And this is why we build an environment, an actual environment with which we actually do work. So all our work happens to this environment. It's free and open source, literally because we need to get the people that are somehow ready by some miracle. ah Even in today's world, some people are more ready than others and they want to get their hands, ah you know, to feel this idea with their hands, not with your hand.
00:51:24
Speaker
You need to feel it with your hands. And that's why we made it free and open source, and it's really extensive. It's called Glamrs Toolkit. um You can go and download it, and there's no commercial thing associated to it. So we we really look at it as ah both as a research vehicle and as an educational platform ah for people to to start learning. but um But still, this will not convince the the majority of people. What I believe will convince the majority of people is aligning principles with money.
00:51:55
Speaker
So people got like, you know, talking about chaos engineering, Netflix made a really strong round when everybody, you know, went down except for Netflix at a certain moment in time, kind of decade and so ago. And then people started to pay attention, and so how come? ah How come that that's that's the case? And because basically they could show money.
00:52:21
Speaker
And it turns out that this is um this is a really interesting catalyst to people. So today we are actually looking for ah we. So I'm the CEO of a company called Think and I think the way we get ourselves the funding to do all this work that we make it free that we make free and open source um is.
00:52:41
Speaker
We actually solve problems. And we solve hard problems. ah In fact, we solve the hardest problems that companies typically have. So we work at the moment with two kinds of companies. um And I'm telling you this not as an advertisement, but to just to to to to your point. On the one hand, there are companies that have crisis. Usually, these are some sort of legacy. They failed really big and or in some one way or another. And they have no idea how to move on. They need some sort of a Hail Mary. So why not try this weird thing?
00:53:11
Speaker
um kind of thing. But there' are those companies, they never learn. They don't want to learn. They just want out of the dead end they're in. On the other side of the spectrum, you have companies that are seeking a competitive advantage.
00:53:25
Speaker
they already look for things it gives them that gives them an edge. They just don't know it. They don't know exactly how it looks, but they see it when they they recognize it when they see it. Now, we don't work with basically anyone in between because we're training, we're a tiny company, just a handful of people or two handfuls of people as well. But because everybody in between requires convincing. So our hope is to find enough people on the on the competitive advantage side of things that will just show everybody else money. yeah and This is what will convince and the rest of the people. Ray, this is me thinking about the ah podcast we recorded recently with Jeremy Adamson.
00:54:09
Speaker
where he was like, here's this great technical thing. And when he went to socialize it across, ah like he opened his books, Geeks with Empathy, where he went to pitch this and was like, they called me a turnip. They said that I was just trying to make myself look good with all this math.
00:54:25
Speaker
And the um yeah he had to go through this process of really understanding what other people found valuable and then how his tool would help them. And in that way, the traction started taking off. So it sounds like you're advocating for a similar ah similar strategy.
00:54:42
Speaker
I, we have, oh my gosh, I can tell like the three of us could talk all day, probably all week and we're very excited. Um, but we do have to wrap up. So our last question that we ask everybody on the show is what do you think is the most important thing that should be happening at the intersection of empathy and technology? I think that, um, focusing on how we feel.
00:55:10
Speaker
um It's really important in our um in our in our domain. And that's because we get to influence everybody else with the work we do in software. and so And unhappy people are unlikely to produce happy solutions.
Conclusion: Empathy Enhances Technology
00:55:28
Speaker
And we really badly need happier solutions yeah um in this new world we create.
00:55:35
Speaker
And um so anything we do, we have to I think we have to really pay attention to that particular thing. Now, in my case, I'm just focused on what I believe to be a fundamental core problem. It's not the only solution that gets us to feeling better um inside software the systems. I just believe that we have to feel better inside software systems. And there is theres one particular perspective that um I read a lot in in a book from 1995, which is called Pantons of Software by Richard Gabriel. And there he came up with this idea of habitability. um So it's this idea that given that we spend as as engineers, and given that we spend most of our active life inside software the systems, ah it should follow that it would be a good idea to make those software systems suitable for human inhabitants.
00:56:31
Speaker
Now, the the what he proposed at the time is is one way, um but I believe um investing in our abilities to see insights of the systems is a fundamental precondition for us to feel um to feel or to improve the way we feel inside ah systems. I'm very sure that this is a very large space. um i I'm also very convinced that whatever we found in in our research um is is absolutely not the end of the conversation. It's the beginning of the conversation.
00:57:06
Speaker
yeah And I believe that it's really important for us as an industry to start talking about how do we reason about the inside of our systems? How do we make it enjoyable or understandable?
00:57:22
Speaker
yeah um And because the one thing that I do know is that once we deem a subject important enough as an industry, we can change it. I love that. Awesome.
00:57:37
Speaker
Tudor, thank you so much for coming on the show, and thanks everyone for listening. This was such a great conversation. Just a reminder, empathy in tech is on a mission to accelerate the responsible adoption of empathy in the technology industry by doing four things. Closing the empathy skills gap by treating empathy as a technical skill. Teaching technical empathy through accessible, affordable, and actionable training. Building community and breaking down harmful stereotypes and tropes.
00:58:05
Speaker
promoting technical empathy for ethics, equity, and social justice. And I can see how this kind of touches on a lot of those things. So if you found this conversation interesting, head over to empathyintech.com. Let's keep the conversation going and join our community of people who are interested in the intersection of empathy and technology. Thanks again for listening and we will see you in the next episode.