Code with Jason
Code with Jason
296 - Software Design Principles with Andrea Laforgia
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Andrea Laforgia about programming principles, why good code is code that's easy to change, and his motto: "write your code so it can be easily deleted." We discuss technical debt as an operating model, the fallacy of sacrificing quality for speed, and AI's impact on learning fundamentals.
Links:
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsense monthly dot com. I'll say it one more time nonsense monthly dot com. And now without further ado, here is today's episode. Hey today I'm here with Andrea Laforgia. Andrea, welcome.
SPEAKER_02:Thank you.
SPEAKER_00:Thank you, Jason. It's nice to be here. Uh so we were just talking before I hit record about the Italian language. Uh you yourself are Italian and you're living in the UK now, right?
SPEAKER_02:Yes, I've been in the UK for 13 years and a half now. I came here in 2012 and I basically spent half of my life in uh professional life in Italy and half in the UK. So yeah, it's been a long time.
SPEAKER_00:Okay. And I'm curious, I I've wondered about this before. Um, what is the tech scene like in Italy? Like for me, I live in Michigan where the tech scene there's not much of a tech scene here. Um and I'm curious what it's like in other parts of the world.
SPEAKER_02:Yeah, it's interesting because I haven't been to Italy for 13 years now, so things have changed. I know things have changed. Um, hopefully for the better, from what I hear from people who still live in Italy. And uh but when I left Italy, uh I could see the difference between Italy and the UK. The UK was a bit more advanced, and the technology landscape in Italy was a bit more like old technology, very old technologies. Like I came from an environment where we were using um Java and JE2EE, typical two early 2000s um architectures, um uh big presence of Oracle and PLSQL. And I I I guess it's probably because of where you work, like if you work in Rome, for example, there's a lot of um public administration stuff, so you're working with governments and typically or large or large organizations, and typically those are very old technologies that you have to maintain for a very long time. So you're kind of forced to work with that legacy system, with those legacy systems. I work in companies where uh the there were systems that had been created in the 60s and they were still running on Vax VMS systems, so uh but they were just working, nobody was touching that. But I I've always felt like Italy was a bit, you know, kind of trying to chase up with other uh catch up, sorry, with other countries in the world. Um I think that Northern Europe and always has always been more advanced technologically speaking. Um, this is my impression. Maybe things are going in a different direction. I know I know that there's a there's a trend in Italy. There's kind of uh uh new interest in XP and uh and companies embracing XP and the um the practice I talk about. Uh there's there's a new renewed interest in these in these things, which which I'm I'm happy about. Um I guess it's also because there's a there's a lot of very innovative companies, um, especially in the north, which has always been more productive than the south. And uh and obviously when you want to be productive, you find these practices really useful for that. So I'm just glad that Italy is is moving forward with these these things.
SPEAKER_00:Okay. Yeah, I always find it interesting the like economic culture or culture and economy and whatever of different regions and stuff like that. It's it's very different from place to place.
SPEAKER_02:Yeah, Italy is is a is a country that has is a beautiful country. If you go there for holiday, it's a bit harder to live there and work there and start a business there, comply with all the Italian regulations and laws. It's a country that carries a big debt, you know, as a as a country. So uh it's always hard to make investments, it's not very attractive to foreign investors because of the rules, the laws, the taxes, and all that stuff. So uh historically has as never been like an attractive destination for investors. Um but I think there's a lot of really um bright and capable people in Italy, and it's just a shame that sometimes you have to move abroad to be able to you know make those skills and and know all this flourish. You have to go to other countries that are less problematic than Italy.
SPEAKER_00:Yeah, yeah, and I'm very thankful for the internet and the rise of remote work and stuff like that, because where I live, there's nothing like I I live in a very small town, um, and and there's nothing here at all. Um, and so online work is the only possibility. I could commute to a nearby city, but even there I'd have very limited options just because I'm I'm not near like a metro area with a lot of jobs.
SPEAKER_02:It it it remote work is is a very good thing, and I think it enabled you know work from different parts of the world. You know, I know that there are companies that are globally distributed, and people contributing from all parts of the world, which is great. Italy, from this point of view, um there is remote work in Italy, but historically, traditionally, um I don't know, companies are a bit reluctant. But again, I haven't been to Italy for 13 years. Maybe things have changed. But when I was there and I left Italy when I was um yeah, 37. Uh, I started work when I was 24, and uh when I started, I mean, even the internet was was was just born, and and uh and technologies were not that advanced to allow remote working. So um yeah, I think there are a few places now that are working remotely, uh at least from my conversations with with people working in Italy, and I'm glad of that. Uh but I think in general the remote model in Italy it's not very uh very common.
SPEAKER_00:So yeah, so I I want to um bring up the reason that I'd I found you and brought you onto the show. Um somehow I kept coming across your LinkedIn posts, and every time I saw something that you wrote, it was like like and reposts. Like it was just like you were really speaking my language. Um and I I I can't recall like specifically um a a a particular instance, but like basically, like again, we were talking pre-show, it's like high-level principles as opposed to like um tidbits about technologies and tools and stuff like that. Because I think uh principles make the biggest impact on your level of productivity. Because I'll I'll take somebody with really strong like let's say I need to build a program in Rust. I've never used Rust before. Um but if if I could hire somebody who also has never used Rust, but they have really good programming principles, um I'd hire them over somebody who's an expert in Rust but doesn't have good principles because the principles make uh by far the majority of the difference.
SPEAKER_02:Yes, absolutely. I I completely agree with that. It's interesting you mentioning Rust because I I was doing an exercise with Rust and AI. Um and I don't know Rust. I I I just wanted to uh see whether I could build something using Rust uh guided by AI. And I managed to do that, and what allowed me to come up with good design was the fact that I knew some principles, right? Some some how to decouple logic, how to correctly design a specific software module. Um, I remember having this um problem with AI, not being able to understand what I meant. Um it was a bit of an experiment for me to also understand whether he could come up with good design on its own. And I could see ended up in a rabbit hole where he wasn't, I was I was implementing the Huffmann compression, and the Hoffman compression needs to speed out bits. Obviously, when you speed up bits, you have to pack them into a bytes and then spit it out to onto a uh byte output stream, right? And for some reason he wasn't able to do that, it would keep everything in memory, right? And I was trying to point it in the direction of creating something that would wrap around an output stream, and obviously that is something that is not necessarily related to Rust, it's just a general principle of how you build stuff that uh gets read as a stream, written as a stream, and and so how do we do that with with with with Rust, right? I I know how to do it with other languages. Um, and so once I was able to tell AI this is what I want, then at that point I kind of unlocked it and it was able to implement that. I don't necessarily know how to do it in Rust, but I gave it the instructions about the designer that I wanted, and it was able to do it. So I completely uh agree with that. This is also the reason why sometimes I don't like those job interviews that focus a lot on on you and this and you remembering how to write something in JavaScript, or it's not completely irrelevant. I mean, that stuff I could Google it. It's more about how you structure your code, how you how you think about the problem, how how you think you're solving it. And that's why sometimes I find that that I found conversations valuable, because from a conversation I can see whether you know how to write good code or not without necessarily you you know typing typing stuff. So yeah, I'm a big fan of uh non-technical conversation as non-coding comes uh interviews.
SPEAKER_00:Yeah, yeah. I've I've always been frustrated by interviews that like pro view for trivia. One of my least favorite interview questions I was ever asked was what's the difference between single strings and single-quoted strings and double-quoted strings in PHP? Um, and it like doesn't really matter that much. Like what they told me, because I didn't know it was like some uh very minor performance difference. And it's like, who gives a shit? Like, what difference does it make whether I happen to know that little piece of trivia or not? You know? Um I I wish they had focused on principles. Um speaking of principles, I I have a question for you. So I had Dave Thomas on the show recently, the author of The Pragmatic Programmer. Um, and I have I asked him a question what which I want to ask you as well, and I'm curious your take on it. Um, how do you decide the difference between a good programming principle and a bad one? When you when you encounter a new principal, how do you decide whether you buy it or not?
SPEAKER_02:Well, it's an interesting question. I think um principles are tricky because it depends on where you are in your career, what kind of experience you have, what kind of seniority you have in your job, and because you if you are young and inexperienced, you tend to follow what others have already, you know, um talked about, they've written books about that stuff. So you kind of assume that that is the good guidelines you have to follow, right? One typical thing is solid principles, for example, right? Solid principles are something that people tend to embrace as is because you know there's plenty of books, people talk about that, there's clean code and all that stuff. And then as you as you mature in your journey, you have the tools to maybe start questioning some of those principles, whether they're good or not, right? In terms of deciding which principles are good or not, my North Star is always does it help me change my code easily? Does it keep it easy to understand, does it keep it easy to maintain, easy to test? Um in general, that that's what I what I follow. I have a motto which is write your code so it can be easily deleted. Because I think as I matured in my journey as a as an engineer, I thought I was enjoying more removing waste rather than adding new code. So refactoring things to simplify things rather than because when you are young, you you you like abstractions, you like to build clever stuff, and then as you become more experienced, you know of all the effects of those things on the evolution of that software. So you tend to go back to simplicity and say, let's keep things simple and let's remove all the way. So, yeah, in general, I think the do the solid principles help me uh keep my code maintainable, clean, understandable, easy to change. That's the quality of of good software, in my opinion. Um, is it is it is it easy to change? Charity Majors was was asking a question the other day on LinkedIn, so she was saying, what is good software? And um and obviously the answer you always get is well software they're easy to change, easy to evolve, right?
SPEAKER_00:I want to dwell on that a second. Um maybe maybe in your circles, the people the people you talk to say that good software is software that's easy to change. Um, and I envy you a little bit because that's exactly the right answer, I think. But if if you ask people like what is good code, um a lot of people uh that's not their answer, their answer is something different. Um and maybe if you like help them think through it for a while, they will arrive at that answer. Um but I I wish that everybody understood that good code is code that's easy to change. I forget if that's exactly how you put it.
SPEAKER_02:Uh yes, I think you know, what is good software is a tricky question because it's it depends on which lens you're looking at it, right? If you look at the lens of a business person, good software is something that allows them to make money, right? That's good software. So um if you ask someone who doesn't know anything about how to build a software system, for them probably good software, they don't care about the quality of your system, they just care about whether they can sell it and and they can make money out of this. So that's good software for them. If you look at um someone down the chain, like uh, I don't know, product manager, good software is something that allows them to add new features you know quickly enough uh to be able to test it with uh with the customers. If you talk to customers, is software that solves their problems. So depending on the stakeholders, everyone can give you a different answer. When it comes to developers who are also stakeholders of that system, they're gonna tell you, well, I want to be able to jump out of the bed in the morning, and if I work with something that is making my life miserable, I wouldn't be able to do that. And if I have to, you know, bang my head on the wall every time I try to change a function or a class, then obviously that's not good software for me. Never mind whether it generates lots of money for the business. So it's funny.
SPEAKER_00:Like I I find so many programmers are just total masochists that they don't mind if their code uh is super painful to work with, and they just make it uh gratuitously complex, like way more complex than it needs to be. And I I just can't identify with that way of being because I'm like you, you know, it's like I I forget which book said uh code is our house and we have to live in it. It's like if you create a a mess, you have to live in that mess, and you're gonna be held accountable for that mess. People like to blame managers for deadlines and stuff like that, but it's like your manager didn't type on the keyboard that was you, you did that, and you're gonna have to live with the consequences, and you're gonna get blamed if your design choices make it so that um you you have problems with the software down the road.
SPEAKER_02:Yeah, I think I think you know it's yeah, it's very true. And uh, and uh the problem is that. Different people have different understanding of what you know good or bad code is, right? You talk to 10 different developers, they're gonna give you different ideas. I've worked with brilliant people who are building very convoluted abstractions and they thought that that those were those were good. I've I've worked with brilliant people who were writing um variable names that were like uh 200 characters long. I'm not kidding. I mean that's a real story. And when I asked them, well, don't you think that's a bit too much? Yeah, that's perfectly reasonable to me. And I so you you get into these these these quarrels where you someone has an opinion about something is completely different from yours, but you don't really have like a strong argument to oppose that. Um, it's more or less like drawing, right? Right. You you like drawing in a certain way, I like drawing in a different way, I like some type of painting, you like different type of painting. So when you look at the code, it's a written artifact, and uh you might like it, I might not like it. Just like we like different books, right? We like different narratives, we like different fictions, right? So it's very complicated when it comes to stuff that comes from human brains, it's very complicated to judge what's good and what's bad. I think in general we have like criteria like does he help me produce new value in an in an agile way, not not in the sense of agile software, but uh in a way that doesn't allow me to that doesn't make me disrupt too much when I want to when I want to uh fix things.
SPEAKER_00:Wait, so I want to go back to something you said a second ago about the uh kind of like taste issue and painting and drawing and stuff like that. Um there's this book that I mentioned, like almost every episode, The Beginning of Infinity by David Deutsch, and he has a chapter in the book on the idea of objective beauty, um, which I find really interesting because I'm in the minority in this opinion, but I've always believed in such a thing as objectively good taste. Um and and the question that's interesting to me is like what determines objectively good taste? It's not popularity because there are things that are extremely popular that are in poor taste and things that are uh unpopular which are in much better taste, and so what determines those things? Um and relatedly uh I've also been working on this this book uh very very piecemeal, very slowly, that I'm calling the philosophy of programming, where I'm trying to say what can be said objectively about programming. Um I I don't think it's all that great for us to have arguments that are just my subjective opinion versus yours. Um, what can we say objectively about various things? Um, and why can we say those objective things so that we can have firm ground to stand on so that we can continually advance the field rather than continuing to have arguments about the same things over and over again. Um anyway, I'll I'll I'll just pause there in case you have any thoughts on that type of thing.
SPEAKER_02:I I completely agree with you. Um this is the other side of the coin. Like you you given that, yeah, people might have different views on what's readable code or not, for example. That's that's one thing that always comes up. What what what does it mean to have readable code, right? Some people readable for who, right? And sometimes you you see posts on LinkedIn saying, do you prefer this or that, right? In terms of you know how the code is structured, and you get half and half, people like one or the other, right? But as you say, and this is the idea behind people don't like this this this expression, but you know, when we say best practices, right? I guess the for me, software engineering is, and again, people don't like this word either, but I see it a bit of a craftsmanship, right? So if you go to shoemaker and you say, What are the tools you use? And he is gonna talk to you about you know the glue they use, the nails they use, the particular technique to put the shoe on, you know, specific on the workbench and so on, right? And that is knowledge that they have built over 40-50 years of of craft. And probably that technique is gonna be shared by someone else that discovered the same benefits of working that way. So, what I always tell people when we talk about, for example, best practices, stuff that we have discovered. This isn't the phrase that they use in the Agile Manifesto that say we are uncovered, uncovering better practices, right? And we want to share that with the world. It's what what what I always say is that don't think that best practice means that that is the absolute best. It's is a set of practices that a number of industry sectors have found valuable, and so you might want to explore that because there's a high chance that that might be valuable for you as well, given that what you do is incredibly similar to what they do.
SPEAKER_00:So what I propose in my book, instead of best practices, is theories. And it's maybe kind of unusual because we don't really talk about programming theories, but I I I think it it strongly mirrors um scientific theories where the idea is everything is tentative. And it's like this this is my theory of how such and such works. Uh, given what we know today, this is the best explanation that we have. Tomorrow we might find a better explanation. Um, and so everything is tentative. And then the significant thing also behind theories is that there's always an explanation. Um, as opposed to a lot of programming rules, which are one of one of my least favorite programming uh theories, if you call it this, is the rule of three, where where people say tolerate two instances of duplication, but not three. Um that is just it's what David Deutsch calls a rule of thumb, which is a rule without an explanation. Um and so I'd prefer us to move away from rules of thumb and toward uh uh theories with explanations behind them and have that mindset of theories with explanations, and that's how we judge them, as opposed to something comes from an authority figure or something like that.
SPEAKER_03:I I I completely agree with the with the idea of a theory.
SPEAKER_02:I it's interest what it's interesting that you're mentioning this because just like for science, when science says this is a theory, right? Theory of relativity, theory of evolution, people uh instinctively interpret that as a wild hypothesis. But in reality, it's an explanation of what we've observed, right? And I like that way of phrasing it because that's exactly what happens with the practices that we have seen work in the industry field, and uh we've we've seen that they produce value. And so we formulate a theory based on that, based on what we have observed, which doesn't necessarily mean they're gonna apply forever. Uh maybe tomorrow we discover something different. Also because the landscape is moving so fast that obviously you when you have the a specific combination of infrastructural power, see cloud computing today, for example, compared to 20 years ago, AI, maybe tomorrow we're gonna have quantum computing. So things are gonna change, they're gonna affect the way we we work with technologies. So we're gonna discover new new practices, which are probably gonna invalidate what we promote today. That's absolutely normal, right? You have to be open-minded and say, what I know today is is the best so far. I know, and tomorrow I'm gonna discover something different that's gonna change my view on things. I yeah, I think, for example, AI is already shaping the way we use certain practices, like TDD, for example, right? Or yeah, continuous integration pairing. I mean, it's uh it's changing things a bit. When you use test human evolving with AI, it's different from what how you when when you use it alone, you know, or with that with another person, right? It's it's it's a different dynamic. Um, and so things are gonna change in the future. I mean, I'm sure we are we are this is the dawn of a new era, and who knows what happens, right? So we have to we have to be open minded.
SPEAKER_00:Yeah, yeah. Um, and another aspect of of you know, there are programming theories, and then there's what you could call programming theory, which is like, you know, there's there's areas of math. Like right now, I've I've been reading a bit about something called queuing theory, which is uh it's all about waiting in lines and and stuff like that. Um and I'm studying that because of um working on CI systems and running test suites and stuff like that. We we need to know how to allocate resources and how to structure the cues and stuff like that, and queuing theory tells us about that. Um but we don't have a lot, not that I've seen at least, we don't have a lot that we call programming theory, which is like um things that are uh uh not not like assertions like this is good and this is bad. We have a lot of that in programming. Um not just assertions about what's good and bad, but like statements about what is fairly uncontroversially true. Like, for example, uh this is what abstraction is, this is what testing is, that kind of stuff.
SPEAKER_02:Yeah, it's it's hard. I think it's hard to do that for programming because um there's so many different ways of doing things and so many different contexts that it's really hard to come up with that that type of assertion, right, about programming practices. And I do think that we should be a bit more experimental in the way we we write software, especially the way companies work, to explore um whether certain practices work or not in their specific context. I'm a big fan of um experiments in the every time you you you tell someone you need to be a bit more experimental, you have to do like um as it called um uh pri new things. They they they come up with hackathon, you know, and and once in three months, one day where you and that's not really what I mean. I mean, how do you embed that experimental model in the way you work so you can try different ways of doing things and come up with a bit of a scientific um deduction from from what you've done, right? It's like like we're using AI with TDD this way, we're using just AI without TDD, what works best in our context? How do we draw a line there and say, for our specific scenario, you know, I mean, pretty much what they do in the scientific world where they do uh double planet experiments or stuff like that, and they infer something from that. Um, companies don't do that uh much, they they just kind of absorb knowledge from outside, they take something for granted, uh, they follow principles for the state could follow those principles necessarily because they work in their specific context. There's a bit of cookie cutler application of of principles in our code cultural. Um analyzing whether they they actually make sense or not.
SPEAKER_00:Yeah. Yeah, it is tough because um it's really impossible to conduct controlled scientific experiments. Um because if if you're conducting an experiment on anything but a production project, then it's totally invalidated. Um but if you're working in a production project, nobody's gonna throw in, you know, nobody's gonna do some kind of test where they where they use some alternate practice that they expect will be that that will have a harmful effect. Because there's something real on the line. You're never gonna use anything, you you're never gonna make a a super risky bet, like, because everybody wants their project to succeed. Yeah, so that that fact that it's impossible to do experiments like that makes things difficult. And I think unfortunately, a lot of people have concluded that that means that programming is not reachable by science and that it's an art. Um, and it is true that programming is part art, like non-scientific art. That's definitely true. Um, but it's certainly not true, in my opinion, that it's completely untouchable by science. Um, because I I think that comes from like a misunderstanding of what science is. Like, I don't think anything is untouchable by science, it is just more uh difficult or easier. Um, because it's it's not just about conducting blind experiments and then checking the result, it's about explanations. You know, does this thing work or not work? And if so, why or why not? And I think we can still do a lot of that.
unknown:Yes.
SPEAKER_02:I I I completely yeah, I agree. Sorry, I'm agreeing a lot with you. I'd but I wish we could disagree and have a more interesting conversation. But what you're saying, I agree a lot with that. The thing is, um, what you're saying is impossible to experiment. Well, that that's really why that's that's why I I have a I have a talk and I talk about technical debt, right? And I explain why technical debt is misunderstood. Because people think technical debt is the accumulation of a lot of crap in a system that is eventually impeding our progress. Well, that's a consequence of ignoring technical debt, but technical debt originally meant something, it was more like an operating model, right? Saying, we don't know enough about this problem, we don't know enough about what a customer needs. We are gonna try something, right? Based on our best knowledge so far, we're gonna try something. When I put it out into production, we're gonna we're gonna we're gonna learn something from it, right? And as we learn, we're gonna go back and align the program to what we learned, right? Which means paying down that knowledge that we've borrowed, right? And and if you do that in iterations, right? Iteration after iteration after iteration, that is a bit of an experimental model where you try different things. So if you do small things in small experiments, and then you learn, and then you you adjust, and then you learn more, and then you adjust, and then you learn more, and you adjust. And that's why I keep saying incurring technical debt is not a problem, it's an operating model. We software engineers across the industry, like a shooting star, have been spending a bit of time here, a bit of time there, a bit of time there. And every domain is different. We we normally don't have enough time once we land a job to learn everything about that domain. We have to do our best by talking to domain experts. What we produce is what we understand, so we need to make sure that we understand the right thing, but something is gonna slip through the cracks and and is not gonna be done correctly. Something's gonna be wrong. So we kind of have to take it for granted that our system is gonna be somehow wrong, right? That's fine, as long as we don't put customers in danger, but that's fine. We're gonna learn, we're gonna, we're gonna, we're gonna fix that. So it's it's this that is missing sometimes because there is this feature factory model where you are put under pressure, and there is never a time when the team can stop and and and reflect and retrospect and say, hang on a second, what what have we built here? Does it really reflect what what the custom what the what the product owner wants, what the customer wants? I remember working in a place where I joined as a tech lead, and the team, every time the team was talking about this concept of ownership between legal entities, the product owner was scared and say, Ha, that's not really what I want, what I mean by ownership. And I said, Hang on a second, we need to stop, sit down, and have a conversation as to what you mean by ownership. And we have to align the system to that because if we keep expanding extending, expanding this drift between your understanding and our understanding, what do you think is going to happen, right? And whether that that could mean renaming classes, renaming functions, restructuring database tables, whatever it means to reflect that knowledge back into the program to align it. That is for me the learning aspect of the work that is aimed at producing good quality in the sense that aims at producing software that does what is supposed to do, reflecting the correct understanding of the domain. And uh yeah, so when I talk about experiments, I talk about having an experimental model, which is your operating model, iteration after iteration after iteration. Because at the end of the day, working iteratively and in increments means managing risk, reducing the risk of doing the wrong thing.
SPEAKER_00:So wow, okay, there's a lot there. So first, I have an alternate model, which I think you might like, um, and an alternative to technical debt. So a couple of things I don't love about technical debt is like with real debt, you can just choose not to have debt, you know, wait until you have the money before you buy something, no debt. Um, but as you mentioned, like in in a software project, there's no avoiding it. Um just by by virtue of the fact that we're not omniscient and the world changes over time, like you're guaranteed to end up with parts of your system that are no longer in sync with reality. It's a guarantee. Um, and so my my my alternate model is dull and sharp blades. Um, because the thing about a blade is a blade will always dull with usage, there's no avoiding it. Um and and so I think that is a closer fit for for a software project because um nobody's doing anything wrong necessarily. Um you're just doing you're acting on your best knowledge today, um, and then inevitably that blade gets dull and you have to spend time sharpening it. So I'm just sharing that because I'm on a campaign to eradicate the term technical debt and replace it with this blade metaphor.
SPEAKER_02:No, I think you're right. It's it's an imperfect, imperfect um uh analogy, uh, which sometimes can break very easily. Um I think it worked originally also because Y Cash, the product the project um Cunningham was working on, was uh was in the financial sector. But I understand I I I agree again. I agree with what you're saying. Um, but uh i in general it's the concept of maintaining something, right? If you don't maintain your house, what what do you think is gonna happen, right? If you don't um service your boiler, what is gonna happen, right? If you don't do regular maintenance for your car, what's gonna happen, right? We we seem to have a pretty clear idea when it comes to those uh things that we have to maintain them in good shape, but for some reason we don't do that with software. We tend to think that software once it's done, then it's gonna be like that forever. And and and and the the thing is software is gonna break. Sooner or later it's gonna break. And the scariest thing that I hear all the time from companies is oh, this system has been uh working for many, many years, never had a problem, so we're not gonna touch it, right? That system is gonna break at some point because the ecosystem around their system is gonna is gonna change, and it's gonna put it to work in conditions that it was not designed for.
SPEAKER_00:Yeah, that's like um Bertrand Russell's turkey. Uh the turkey, and every day the farmer comes and feeds this feeds the turkey, and so the turkey thinks everything's great, but then one day uh Thanksgiving comes and and no more turkey. Um because yeah, one one day with that old creaky system, something's gonna happen and there might be a disaster.
SPEAKER_02:I mean, it it's only a matter of time because the the landscape around that service changes. So, how can you trust that that service is gonna work as it always worked? Uh it's gonna it's gonna break at some point. And fundamentally, it's like having an engine that keeps going. You never put oil in it, and and you just trust that the oil that is there is gonna keep working. At some point, it's gonna break down. And uh that happens to software as well, maybe in in the longer term, but it happens to software as well. I have seen it happen. And I've seen companies where they don't even have the original, they don't even have developers who maintain that code anymore. Wow. And that's even scarier, right? Because it's because it's what even if there's a CVE too long, right?
SPEAKER_00:Right, that's a vulnerable position. Um, you you mentioned about how you know we people understand that machines need maintenance, cars, and stuff like that, um, but with software it's it's different. I hypothesize that a big part of the reason is because, well, for one, uh it's a lot of times different people calling the shots and doing the actual work. And so the the people who are the the bosses, they just want more and more um value to be created. They want new stuff, um, and just human nature. They don't want to they don't want to stop and make investments. Uh they don't they don't want to tend to the golden goose, they just want the golden eggs. They want to squeeze that golden goose as hard as they can to get as many golden eggs as they can, um, which is obviously like a uh short-term benefit for a long-term detriment. Um and another reason is because it takes a huge amount of discipline on the programmer's part. You have to really like swim upstream. Um I I said the thing about code is our house and we have to live in it. Um it takes a lot of discipline to say, like, okay, there's all this pressure, people breathing down my neck to deliver new features. But if I do exactly as I'm told, I'm gonna be in a bad place and I'm not gonna be, I'm I'm not gonna sustainably be able to do what people are asking me. And when they ask me why I can't, my answer has to be because I did a bad job maintaining the system. And so you have to force there to be some time to do that maintenance, but it's extremely hard organizationally and psychologically and emotionally and all that stuff. There are so many forces acting against that, and I think that's a big part of the reason it rarely happens.
SPEAKER_02:Yeah, I think it's it's a very good point. I think the this is one of the reasons why I keep telling teams do not create two different backlogs for different types of work. Like, because typically what happens in organizations that teams are gonna create, they're gonna have one backlog for ordinary work, and then they create a backlog for tech debt, right? Which all sorts of tickets in there with all sorts of technical, incomprehensible language, right? Cryptic to the program managers, but it's A, that's an engineering thing, right? And then they go like, well, it's print-based print, we plan 80% from the normal backlog and 20% from the tech debt. And in the long term, we're gonna we're gonna clean all that stuff. And obviously, what happens is that the business pressure prevails on that, on the willingness to keep the system clean. And so you're gonna focus on that backlog and not on the other one, it's gonna get neglected. And I've been in situations where I had tickets that were like a one-year or two-year-old, where they were actually created at a time as a matter of urgency, maybe, or something to clean at some point in the short term, and they were neglected for a year and a half, people had left, nobody remembered where they were. We deleted the ticket. So I keep telling people when you create a ticket for something that has technical work, don't classify it as technical work. Express it in a language that the business understands. Surface the risk associated, the business risk associated to that uh work. I in my talk about technical debt, I give a couple of examples of tickets that are written with a very technical language that the product owner doesn't understand. How to translate that, exactly the same work, but how to translate that in terms that highlight the business risk, in terms of impact of the user, uh financial risk, you know, security compliance risk, and all that stuff. So that's what you think.
SPEAKER_00:Uh the these projects of paying down technical debt or what I would call sharpening the blade. Um, do you think these projects should be connected to business value? Is that what you're saying?
SPEAKER_02:Absolutely. Um I I think it should be one single backlog of work where the product owner can clearly see that what you're saying, that the reason why you need to migrate from Redis to Kafka is expressed in terms of how much we're gonna uh how much that's gonna impact on uh reliability of the system, uh response time for the user, ability to be compliant with with you know security uh rules and all that stuff. They are seeing that as really valuable work and they're gonna prioritize it.
SPEAKER_00:Yeah, yeah, I totally agree. Um, you know, when when teams surface their their technical debt work, um it rarely has the desired effect. Like managers rarely, almost never are gonna prioritize the cleanup work over the the business work. Um it just has to be like below the surface. Um there's there's something my friend Steven Anderson from BendyWorks said um um one time. He he gave the analogy of like a surgeon, and the surgeon is like, Do you want me to wash my hands before the surgery? He asked that of the patient. Um, and it's like that would obviously be so inappropriate for a surgeon to ask that. Um, but I've I've heard so many times uh the argument that a programmer should should say, like, okay, well, we can do this project in three weeks, but it'll have this negative effect on long-term maintainability, or we can do it on in six weeks, and we'll have better long-term maintainability. I'm presenting you with the options, which one do you choose, manager? Um, and it superficially sounds very responsible. Um, but I think it's totally not, because that again is like the surgeon saying, Okay, dear patient, I can either wash my hands and it'll have this outcome, or I can skip washing my hands and that has these pros and cons. Which do you choose? I think it's the exact same thing, but unlike in a surgery, where obviously the patient is always going to want the surgeon to wash their hands, um, in programming projects, the manager's never gonna want the version that takes longer but has the maintenance stuff built in. That's part of your job as a programmer.
SPEAKER_02:Yeah, yeah, yeah. Well, sometimes developers do that because it's a it's a it's a way to survive in an environment that pushes you to have like a estimate or stuff like that. So obviously they come up with uh with uh options where um you go, you know, the there's 90% chances that we're gonna do it in six weeks, and there's uh 50% chances we're gonna do it in three, right? I don't think any of those plans should ever sacrifice quality. So the options should never be about you can have something low quality now versus something high quality later. This is the big misunderstanding behind technical debt. And it's it's it's a it's a problem startups end up in all the time. Uh, Uncle Bob, I know he's a controversial figure, but he called it um the startup trap. And I think he's right, because there's this this notion that you can go fast by ignoring quality. Um and uh and and that's really something you pay a lot down the line, you know, when you when you start scaling and you now have problems because you can't scale it uh fast enough, and and investors are getting nervous because they say, Oh, I put a lot of money, you're not going to the pace I was expecting you to go. This is the reason why I get pissed when people say um customers don't care about your Intel.
SPEAKER_00:I hate that so much.
SPEAKER_02:Because if you buy a car, yeah, I might not be totally interested in how you put the engine together, but if I start having problems and I got go to a mechanic and they make me look under the hood and say, look at all the crap these guys have done on the assistant. Well, then I'm gonna start maybe next time not gonna buy that brand anymore, right?
SPEAKER_00:So yeah, customers patients don't care about hand washing, you know.
SPEAKER_02:Exactly, right? It's the same principle, right? If I get an infection, well then I'm gonna start questioning the the high I'm gonna shoe your hands and gonna start and if you're not we're not washing your hands, well you're gonna pay for that, right?
SPEAKER_00:So yeah, yeah, and and to comment on something else you said, like um the the the startup trap, I I think you said. Yes. Um and I love that Bob Martin quote, the only way to go fast is to go well. Like often people treat speed and I hate the term quality also, but like they they treat speed and quality as two ends of a trade-off, but it's not a trade-off. Like it's only called good code because it allows you to go fast, otherwise it wouldn't be good. That's that's what good means.
SPEAKER_02:Exactly. And and that's the concept of agility, right? If you look at agility in sports, I mean uh Joshua Karievsky has written a wonderful book called Joy of Agility. I I suggest reading it, it's it's fantastic, it's probably the best book on agility a person could read. And we when we look at athletes, they are fast, but they are stable, so they are fast. I know you don't like quality, but the quality of their going fast is high, right? Because they are stable, they don't go fast and fall all the time, right? And that's also why when you look at metrics like Dora, for example, the Dora metrics, they are basically looking at speed, so deployment frequency, daytime changes, but also stability. What's the change field rate? What's the mean time to recovery, right? And and it doesn't really make sense to analyze one set of metrics without the others. You don't want to go fast, you don't want to launch a lot of rockets that explode mid-flight, but you don't want to be too slow at launching rockets either. So you want the right the right level there, right? To be competitive. So what you're saying is exactly the concept of being agile. We want to go fast, but we want to go well without sacrificing quality. That's the stability of the system.
SPEAKER_00:Yeah. Yeah, and the the startup trap thing, I've I've heard about I've heard about that exact same thing, but uh maybe in different words. And I've always thought so like the the overwhelmingly prevailing position on this topic is that the smart, responsible way to do it is to make a giant mess and then clean it up later, which to me is just so idiotic. Um because yeah, it it's a confusion. Again, the the only way to go fast is to go well. If if if you start making a mess, you're gonna start paying for that uh uh very soon. You know, you're not gonna pay for that in five or ten years, you're gonna start paying for that like in months, if not weeks or days. Um and and the cleanup part, the cleanup part is so staggeringly expensive. Um and and and the cleanup, you know, the the reality is that the cleanup almost never actually happens. They just make a mess and then they live with the mess for decades after that. Like I've worked with organizations that have been around for 10 or 20 years, and they're still deeply and fundamentally shackled by the decisions that were made years and years ago.
SPEAKER_02:Absolutely, absolutely. I've seen that a lot in my 30 years of being a software engineer. I I cannot count on the number of times where I've seen uh products that were born as MVPs with this idea that MVP could ignore quality because it had to go uh it had we had to find um you know, we had to go to production as soon as possible to to to to to you know to be able to produce something. And uh and that affected the system in the long term. And I cannot count the problems that could relate to that initial nature as an MVP in the product. I remember working on a slope working system, order to cash, where uh the customers could place orders for the stock market. And uh obviously, if they were uh changing something in that order that would affect all the calculation uh and and the water and the order was still in progress, that would restart the process, right? Which makes sense because you have to recalculate a number of things. But if they wanted to add a note to the order, it doesn't change anything, it's just a comment you added to the process. That had to restart the order as well. And the customers say, Well, why is that? Well, the uh programmers analyzed that and say, well, we can't we can't change that, it's too expensive to change that. So the problem is that people have this idea that we can do it really badly now, we're gonna clean it up later. But the problem is the cleanup is not always possible, you know, it's not always economically viable. This is why I can I tell people not all migrations can be done. When you work on something, and at some point you realize you have to migrate somewhere else. Well, the damage is done. If you haven't paid attention whilst you were building that system to make it maintainable and maybe portable to another platform, by the time you build the whole crap, it's it's better to just give up and keep the system as is. And this is actually the reason why we have so many systems that have been their legacy forever, never never changed. I I know companies who have tried for 10 years to move away from databases. And and this database was growing and growing and growing and growing and growing. And I when they wanted to move it to another platform, they couldn't.
SPEAKER_00:Because the cost of moving wasn't yeah, yeah, and I I I had a thought the other day. Um it's a it's a thought I've had a lot of times. Like businesses will often get ossified to the point where they can't change. And by business I mean like the whole thing, including the the technical infrastructure and stuff like that, uh software systems. Um they'll get to a point where they can't change. Um and they don't they don't grow simpler and then uh change the simple system. They they just die. Um it's it's like biological species, you know. Species don't ever evolve to become simpler. Humans aren't gonna de-evolve into bacteria and then evolve into something completely different. We're just gonna go extinct and something else will take our place, just like has has happened with um, you know, 99 plus percent of all the species that have ever existed. Um, same thing with businesses and software systems. And I think it's not coincidental. I think it's probably due to the same underlying um laws of reality that like once something it's it's it's a lot easier to grow more complex than it is to get simpler. Um, because there's more incentives, like there's a bigger, there's more of a payoff to getting more complex. Like there can be an opportunity that you can capitalize on by getting a little bit more complex, but it's rare that there's an opportunity you can capitalize on by getting rid of something and becoming simpler. Um and and so I think that's why these businesses just grow and then they get stuck the way they are, and eventually they just die and something else takes its place.
SPEAKER_03:Yes, yes, I agree. Yeah, yeah. I've seen that I've seen that a lot.
SPEAKER_00:Yeah, and and you know, the reason I say that is because if people succumb to this fallacy that the way to build a startup is to make a big mess and then clean it up later, you're probably not gonna clean it up later. Um, and you're probably gonna just die and something else will take your place.
SPEAKER_02:Yes, and and this is something that has been exacerbated by using AI because obviously AI is now giving people starry eyes because they they like like they they go like, oh, now we don't need those idiot developers, we can do everything ourselves, we can't just enter a request, and we're gonna impress that you're gonna have like a system. Yesterday, a colleague of mine was showing me a very impressive way of building a photo library, and uh, and yes, it's impressive. You you you clearly the guy knew what he was doing by instructing the AI. Uh, but then what happens is you you own the problem, you don't own the solution. Um, when it comes to photolibrary, okay, that's fine. But when you work in a military system or a medical system and you have to put lives at in danger, you don't Really want to put in production something you have no control of. And this is this is something I'm hearing a lot of people who are actively saying you don't need to follow good programming principles anymore because the code is just an internal thing now. What counts is the prompts that you give to AI. AI is still able to work with crappy code and uh generate generate crappy code that works, right? Well, what happens when AI ends up in a rabbit hole and it doesn't know how to solve a specific problem with that code and you have to intervene on that code? And the funny thing is that I do think that good principles apply to AI as much as they apply to humans, because if you have robots um in Amazon stores and you and you are and they are you know moving stuff around, do you want a clean environment for them? Or do you or because they are robots doesn't mean that they are efficient and moving in a in a dirty environment around them? Yeah, they can probably avoid the dirt, but you'd really want to keep the environment clean. So if you if you keep a clean code, AI is going to be able to work with that code better. Because in merely replicating the mechanism we use could work, we work with the code, right? They apply uh when I build code agents to review the code, I go, I say, okay, go to this website, read everything about this code smells, code refactoring methods, uh design patterns, and so on. So it's it's learning from what we humans do. And so it's applying the principles that we humans uh came up with. Um and so, yeah, so the clean code is helpful to AI as well. That's that's my theory.
SPEAKER_00:Yeah, I agree. Um, and you don't want your program to be a black box because it's like I I've heard of like uh really technology laden cars and even like tractors. Um where like I I heard about this farmer who bought this John Deere tractor and it was very technology heavy, and something with the tracker tractor broke, and the farmer didn't have the capability to fix it, it could only be fixed by John Deere. Um it's like well that sucks. That's like a crappy model for owning machinery. Uh like it's so much better if you can buy the machinery and at least in principle be capable of understanding it. You know, if I bought a tractor and it broke, it would take me forever to fix it because I'm not a mechanic, but at least in principle, I can fix it because I can learn how the tractor works, it is comprehensible. Um, but if I have a tractor that is built by um, you know, analogously, the John Deere programmers and engineers are the AI in this situation. If they make a tractor that's incomprehensible to me, um and the only way to fix it is to be a hundred percent dependent on John Deere and I have to go to them for absolutely everything, I think that kind of sucks. Um so I I wouldn't want to be in that position with an AI-generated program.
SPEAKER_02:Yeah, no, yeah, absolutely. I I don't think we're we we are at a point yet where we can rely on AI pretty much like we relied on compilers at the time that compilers came about, because this is the other flawed analogy that people use all the time, right? It's like we are at a new, I do think we are at the at the start of a new revolution in the way we interact with machines. But when we say AI is like compilers, at the time compilers were taking high-level symbolic language and translating it into machine code. Um, well, I don't think the analogy really works that way. Um it's it's it's it's it's it's different. It's it's it that that is merely replicate. It's it's fundamentally the difference between complication and complexity, right? Complication is about complicated is about doing something highly deterministic. What what a compiler does is complicated. Well, complex is what uh it's it's it's more than the sum of its parts, right? So it's it's there's emergence in complexity, right? The new behaviors that come up from from the interaction of all the parts of that system. And what I and what I find is that when we interact with AI, it's much more than just the sum of its parts. It's it's more like something new is emerging from that from that interaction, something different. Um uh and so yes, I think it it's the example with a tractor you would make, it's even worse because I think it's if a tractor breaks down, AI using AI is like asking the tractor to fix itself, which is even more difficult. Um because sometimes this is this is the thing, you you have a problem, AI gives you. I've been in this situation many times. You have you ask AI to solve a problem, it comes up with a solution, it's not good enough. You ask AI to fix it, and it and you can't get out of that rabbit hole.
SPEAKER_00:Yep, it paints itself into a corner.
SPEAKER_02:So how do you how do you solve that? I as a developer can roll up my sleeves and go into the code and say, okay, let's look at this mess, let's try to fix it. I'm gonna curse a lot, obviously, but I can do that. But if if someone who doesn't have any knowledge about uh development does that, how are they gonna get out of that situation? And the the stuff that really concerns me is that these I have a lot of experience on my back as a software engineer to be able to understand when AI is doing a good job or not. And I can interfere, I can you know work on the code, jump in if anything goes wrong. But the new generation that is born with AI at their disposal doing a lot of work for them, where are they gonna learn those principles? Where are they gonna learn those foundations that allow them to check whether AI is doing a good work or not? That's why I I I've heard CEOs say, I banned AI for my juniors. And I'm like, you don't really want to do that because they because they allow using AI, they only allow their seniors to use AI, not the juniors. I'm like, well, how does that work, right? You create some discrimination, you still need to involve juniors in that process. Yeah, you're working with seniors to and use AI, but you want seniors to explain to juniors what is coming out of AI, explain the principles to coach the juniors on the good principles. Um, because otherwise, where where are they gonna learn? How they're gonna have the tools tomorrow to to understand whether it's it's good or bad work coming out of AI.
SPEAKER_00:Right. I think that's a really good point. Um, and it's it it creates for a scary but also very interesting future.
SPEAKER_02:Yeah, yeah. I hope I'm retired by this time. Yeah, me too.
SPEAKER_00:Um well that's probably a good place to leave it. Um before we go, Andreas, is there anywhere you want to um share for people to go online and learn more about you and what you're up to?
SPEAKER_02:Well, I have uh quite an active profile on LinkedIn, so please connect with me. We can have good chats. I've uh opened my profile to have chats with people. Uh next week, uh next week, I'll be available for chats if you want to discuss anything related to software engineering principles, uh, how to organize work, how to organize teams, how to make teams high performing. I'm a big fan of uh strength-based development, testing enrollment, and and mobbing pairing, so anyone who's interested in that stuff can let's have a chat.
SPEAKER_00:Great. Well, Andrea, thanks so much for coming on the show.
SPEAKER_02:Thank you, Jason. It was a pleasure.