Science

The Secret To High-Quality Code with Dr. Michaela Greiler and Liran Haimovitch

In this episode, I talk to Liran Haimovitch, CTO of Rookout – an effortless debugging tool, about how to get to high-quality code.

We talk about:

  • what are the challenges of moving fast
  • what does productivity mean
  • a lot about code reviews
  • and I also give you a glimpse of the research I’m currently doing.

Book your awesomecodereview.com workshop!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript:

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

 

Michaela: Hello and welcome to the software engineering unlocked podcast. I’m your host dr. Michaela and today I have a special episode for you. Two weeks ago I talked with Liran haimovitch,the CTO of Rookout – an effortless debugging tool. Our conversation was so much fun and somebody on Twitter asked me if I could make it an episode on, and i thought, that’s a brilliant idea. So, today I’m sharing my talk with Liran on the challenges and strategies for getting to high-quality software. Enjoy.

maror:[00:00:00] Um, hi everyone. And welcome to our webinar today on the secret to high quality code. We’re really excited to have you all here with us. Uh, so let me introduce you to Dr. McKayla and the stars of today’s webinar. Dr. McKayla has been helping software teams build high quality software in an efficient and effective way for 10 years. And her mission is to lead teams. So I’m up there full potential through company workshops and team coaching sessions. Leanne is the co-founder and CTO of workout, which is a live data collection and debugging platform. He’s an advocate of modern software methodologies like agile lean and DevOps, and his passion is to understand how software actually works. So when he’s not thinking of code, which is rarely usually diving, hiking, or writing a new workout blog. Um, and so before we get started, I just want to remind you all that we do have time for questions at the end of the webinar. So please don’t hesitate to leave questions in the question box and this will be recorded and we will be sending you the recording at the end. So. You’re on and McKayla, please take it away.

michaela: [00:01:02] Thank you so much for your really nice and kind introduction. I’m really excited to talk with Liren today about, um, high quality code and get his whole perspective on this topic and pick his brain. So yeah, I’m really thrilled to be here. It’s

liran:[00:01:19] great to be here with you discuss so many interesting topics.

michaela:[00:01:24] Yeah, really cool. So in, in the beginning we discussed a little bit, like what should this webinar be about? And we thought like, let’s come up with this idea that we are asking each other a little bit questions that, you know, are burning questions for ourselves or that we very often, you know, encounter. And, um, so I want to start with that theme and I want to ask you about. The challenge that you see, or the challenges that you see that, uh, engineering teams face nowadays, but really moving fast. Right? So there’s like this accelerate the book, for example, there, the Durham metrics are many other metrics around code velocity. So it’s apparently something that we want to do, right. We want to move fast. We want to be productive, but what are the challenges and how can we actually achieve that? So

liran:[00:02:12] I can say from my personal experience as well from pretty much everything I read on the topic, the best way to move faster is to work in smaller units. You mentioned Dora, the Dora metrics and accelerate, and they’re constantly about, you know, roundtrip time for new features and the amount of new features that are being released. And how can we build in it? How can we work in smaller unit to Falk? And the reason for that is because smaller units of work allow for much faster Predix cycles that allow you to learn much more. You get more feedback, you get, you learn every step of the way you learn more often, and you also get delivered more value to the cost, to the end customer on a more frequent basis. And in a way that’s actually driving a lot more value. I guess the biggest challenge is actually, how, how do you do that? How can you keep moving ever faster? How can you deliver in smaller units while still keeping delivery efficient? And I found that one of the best way, the best way to start is quite often culture. And we talked a bit about you, eh, doing some rich recent research for that. So I would love to hear about. What do you think about how best to build a better culture and how to promote a culture that deliver faster and deliver in smaller units folk?

michaela:[00:03:34] Um, I’m a big advocate for, for great, uh, culture, right? Who isn’t somehow everybody wants to work at the company that has a great culture, but unfortunately not everybody is I’m currently actually doing a research project that I that’s. The one that I talked with you about a little bit is on productivity and work culture and the experiences of developers at their companies. And so I’m, I’m doing right now, a qualitative study, a grounded theory study where I’m really. Trying to deeply understand how are people experiencing their work place and what factors are influencing their satisfaction, their happiness, their productivity, and what, what enables them to move fast, as you said, to be productive, to be the best selves. And, you know, there are some factors around obviously release, for example, is one that’s also covered by the Dora metric. Um, how has the release experience? And here I’m not only talking about metrics because. I think on one hand, I’m extremely data-driven. Um, whenever I was working with teams or am working with teams, um, also at Microsoft, we did a lot of the research was very data-driven, but it was also, and this was very, very important for me, always. Um, Kwon qualitative as well. Right? So not only you’re looking at the data, which gives you a very include complete picture, but you’re understanding, trying to understand the whole experience. And so this research study is really looking at the whole lift experience of developers. So on one hand we have like metrics like, um, you know, release cadence or from time to commit or from time to merge and so on. So what what’s very quantitative quantifiable, but on the other hand, you have. Um, the impressions and the perceptions of people around that. Right? So are you feeling better with it are, um, are they feeling worse and the same is true for code reviews and so. A lot of the things can really back to culture and culture is somehow enabler here, right? So we have like this practices around those areas, let’s say release. These feedback loops that we have released is actually a feedback loop. Code reviews are a feedback loop, right? Talking with product management is a feedback loop. How, how seamless, how smooth can we make them? And culture is really an enabler for that. Why is it an enabler? Because if I’m allowed to say, if something is wrong or if I’m allowed to experiment, even experimented with some failures, right? Like I try something out, I try to work different with product management. It doesn’t work out what happens, right? What are the consequences of that? And. And that’s why culture is so important because if people feel that they can experiment, if they feel that they can also express their opinion on it, they will drive more improvement. Right. Um, the research is really a lot about improvement. How, how much improvement can people. Um, drive and they normally know what’s good. Right. They know what’s going bad. Um, or what’s good. And so it’s really about enabling them to act upon that. And that has a lot to do in here. The funny thing here is that metrics are really important to want on one hand, to enable people that we see and that we make it visible that there are problems. But on the other hand, metrics often also hold people back. Because if I’m, if I measured. By one metric. Right? Um, it means that if I’m trying something else, something new, that’s not covered by this metric. It very well, it could very well be that I’m actually slowing down or I’m. The metrics outcomes going down while I’m trying something out. Right. And so the question is really about culture here. Again, how are people handling that? Right? Do I always have to perform to my OKR or KPIs or whatnot, right. The metrics and the goals that set around, or am I actually allowed to experie experiment here with things that might slow us down for a short time when I’m doing the improvements, because improvements are really hard to do without. Short term slowing down, right? Technical debt. How are you going to work on technical debt and still keep the features going? Right? Yeah. So this is what I am seeing here

liran:[00:07:41] that actually brings to mind the analogy from lean production, where you stop the line. When you see something is wrong and you say you have the, you give a individual engineers or individual employees, the. The permission to call it, to stop the line and spend the time and efforts to improve things, even at the cost of lost productivity in the short term, because it allows for continuous improvement.

michaela:[00:08:09] Yeah, exactly. It’s a really good analogy. Yeah. I

liran:[00:08:13] think it’s so important to create. Um, I remember I talked a lot about feedback, but you’re right. It’s critical that it’s not just enough to have feedback, but it’s super critical that the feedback experience is going to be positive. Even if this feedback is negative, it’s important for people to be able to experience. Getting feedback, something positive and in a way that if they’re changing something or developing something, or if it’s a bad product idea that the negative feedback should be, you know, about the, the, the feature about the, the task that this feature was bad, but the person who came up with it wasn’t bad and they didn’t necessarily make a bad choice by, uh, you know, going after this feature. And. People should be glad about getting those so-called negative feedbacks and not attribute them personally. And that’s super important to the culture, to the experience, kind of, how do you go about creating that? How do you go about building that environment where you get continuous feedback and experience is good.

michaela:[00:09:23] Yeah. I mean, I’m, I’m, I’m thinking a lot about culture nowadays and, you know, to. The common sense is always all countries so hard, right? It’s so hard to change. And if I’m in a, in a bad place, you know, it’s a bad place. Um, and I think on one hand, that’s probably true, but I don’t hand now that I’m confronted. So, so a lot with that, and I’m really working a lot with organizations and that they in displaced, I’m thinking about the small things that you can do. And culture really begins now really coming back to something very concrete. Um, I’m all about code review. So culture begins already in cultural views and for example, code root feedback. And to, in my workshop, what I do, I work with people on how to give respectful feedback. And very often everybody thinks like, Oh, but I’m doing this right? Like we are not fighting in the code reviews or whatnot, or, you know, or it’s only instances of that where we are mean, but it’s more, it’s about the collective awareness of not only do I fight with somebody or, you know, is it an unrespectful, but really. Uh, is my mind about value? The value that I can provide to others is the, is my mind about how can I actually, you know, improve the experience of my peers here. And I think this is something that’s often not done, and this is something very small where a team can really. Start actively being more aware of that, more deliberate, more conscious about this. Um, and it starts already by understanding code is really, really hard and everybody has, um, everybody has a time pressure and you know, wants to deliver the features. And a lot of engineers say, well, you know, code review is good, but, uh, I actually have to deliver feature. So what’s about the time that I have to spend on the code review. Somehow it’s missing from my feature work and so on. And so having really empathy around that and the experience of myself, but also off my, off my team, that’s already creating culture, um, and being extremely, um, it bear that feedback, even if it comes from a good colleague that you think like, we are all, you know, good friends and we are really on the same page that we still really take. And this is now again, you know, slowing down, right. It’s slowing down to make sure that I’m phrasing this feedback in a very respectful way, because we know that feedback can sting. Right. Um, and it can be misinterpreted. A lot of the feedback comes through a tool, which means it’s an automated tool. I’m not directly talking to a person. So sometimes I forget it. And we are in this automated way of. Um, you know, looking through the algorithms, finding, you know, let’s say edge cases or whatnot, finding problems. And so if you are in a very technical state of mind, and then we are hammering in our feedback and say, Oh, Variable name is wrong or, you know, or should be different. And then going, you know, taking one step back and thinking, is that creating a good culture? Or can I take this, you know, two more minutes and say, Oh, you know, what about, um, renaming this and even giving an explanation, you know, w really expressing your, your mind. I think. Driving cultural change is definitely hard and, um, comes often also from the top, but there is a lot that teams can do for themselves. And even engineers themselves can ask themselves every day, like, what did I do positive today? Like I’m not only going somewhere in and they’re expecting that culture would be great, but am I actually contributing to, to making a good culture here? Hmm.

liran:[00:12:49] I think it’s so much more critical today as well, working remotely, because as you mentioned, we’re often in that technical state of mind, whether it’s on GitHub doing code review or on Slack or wherever, but behind what’s actually happening is we’re communicating with other human beings. We’re not just no analyzing code and the testing stuff we’re communicating to other human beings. And as we were, many of us are working remotely quite often, or most of the time. We can often forget there is a person on the other, on the other side of it. And sometimes we kind of forget to act with empathy, with compassion, and while we may be factually, correct. We’re not creating a good experience for the person on the other side of that communication.

michaela:[00:13:35] Yeah. And actually about the factually correct thing. I have learned over my, you know, my time in the industry that at seldom leader, Kate seldom Livia are very, very active, you know? And I think sometimes you forget about that and, and this is two perspectives. Cultural views are a place where two perspectives really are, you know, they are, they are the benefit of it. And there are also the problem, right? That you are constantly having somebody that looks at the same thing and say, well, but I’m seeing something else, right? Like I’m seeing technical debt and you say, but it’s fine. You know,

liran:[00:14:15] the thing is engineers so often feel like they’re factually correct. Even whether it’s or not, it’s the case. I just, and quite often we’re not actually factually correct. There is some degree of, eh, you know, afraid. Of common sense and various options. And w there is not one single truth out there, but even if there is even if you there is, and you’re convinced that there is in your, on that single spruce, it’s still communication. And you must not forget that there are other things beyond fact, too, and more often than not, there are actually no facts. And it’s just your opinion, which might be very good and professional, but it’s just an opinion.

michaela:[00:14:59] Yeah, very true. And a lot of the time it’s about strategies. And about the unknowns that you know, that the unknowns unknowns that we actually make guesses and decision and B we don’t know if they are the best ones. And we even in hindsight, we cannot decide like if we could have, you know, if you would have done it differently, would we have a better outcome? We don’t know. Right. So, yeah, it’s, it’s, it’s really dealing with that and, and embracing that and maybe reminding maybe something that we can do also, always over time to build this culture is reminding us of that. Right. It’s a little bit like we have to remind ourselves of the central things. We have to remind also ourselves that we are dealing with so many unknowns and that on one hand, you know, we are, I think at, at one point we have to go and say, Well, we don’t know better. And maybe some people disagree here, but now is the time that we are, you know, buying in and going this way together. And I think this is also important for engineering teams, right? So in one of my country workshops last week, for example, I give them a code base and it was, um, it seeded with errors, right? So it has issues and they asked the team to, to find those issues. And there are, you know, they are. Issues about readability, maintainability of the code, but there are also security issues. And so then we had a discussion about, you know, um, so there are a lot of issues. So how are you going to communicate to the person that wrote that code about those issues? Are you going to tell them all of them at once? You know, do we make like a plan around what should be, um, worked on first? And there was, for example, this discussion then between two senior engineers and they were saying, well, once by saying. Yeah. Um, so everybody agreed that, you know, sending them 300, 300 problems at one point is not the right thing to work with this junior. So, um, they were thinking, well, let’s do it in, in phases, but it didn’t, they couldn’t agree. Like if security issues are more important than readability issues or not only readability, but making the code work. Right. So there was this discussion that, well, this is early stage, so it’s, it’s probably a prototype, so we should have to, you know, show. So let’s do it. Make it correct first that it works and then work on the security issues that they had, like they had, there were injection box and cross site scripting products and so on. Right. But in the end, you know, like the whole team was discussing it. They couldn’t really find a way forward. Right. There was one side that was very convinced that, well, these are really critical security packs and they were really critical. And the other was like, well, but it’s, you know, we use it internally right now. It’s a prototype. So let’s make the functionality work first. And so what, there was a back and forth, and I think this was a really nice example of, I couldn’t tell, like, I couldn’t say like they wanted me to be now the referee and say, Oh, you win. Right? Like the security team, Vince, we first do a security or we first do inability, but there is no right or wrong answer. It’s just the strategy that you’re going to do. And probably that you’re not doing, you know, again, not sending all the issues at one is a good one. Um, but then in the end, it doesn’t matter if you do one or the other, as long as the security backs are not coming out right. In, in production. Um, yeah. And, and I think here it’s really important to step back from this discussion at one point and say it’s actually a nonsense discussion. Let’s, you know, flip a coin and do one or the other. Um, yeah, this is what I think about this. So a lot of the things is really. It really depends. And then we have to make a decision and if we made the decision, this is the important thing. And then everybody has to buy in and not like, keep this resentment and say, Oh, the security or pre approach first. Right. And I think it’s stupid. And so that’s why I’m blocking here, which is culture. I think.

liran:[00:18:49] Yeah. So actually it’s not, it’s interesting that you mentioned that because it’s such a big topic. And I mean, so much effort goes into code reviews and often becoming the button neck, both for whoever has to do the code review. And, you know, spend the time and walk and provided feedback in both wherever need, wants to get, just to get this code out there. And they’re just trying to, and, you know, they’ve just finished developing the feature. They just want to check off the it’s been called of you and send it out there. So kind of what strategies should company follow to speed up their code reviews?

michaela:[00:19:27] So, um, I totally agree that code reviews can become a bottleneck and they’re coming with a lot of pain points, but I think especially this. This mindset of, you know, cultivate is just another hurdle. Um, that’s something that people have to work on. Right. So, um, we really have to understand and carve out also, what’s the benefit of the code view? Why do we do it even here? Right. And if the feeling of the engineering as well, I just wants, uh, I want to look good to me and that’s it. Um, then obviously it’s a delay and it’s a bottleneck and you know, the value. Probably isn’t that high because even if the person gets good feedback, you know, if the person that receives it, doesn’t actually want it, you know, what’s the value of that. So I think that a lot of those is really for an organization and for a team to think about what do we want to get out of contribution? And there is a lot of imperative studies also that really show that the benefits like. Um, improved code base, readability, maintainability, um, less, you know, less issues, less facts, defects in posts and pre-releases, um, all of those are happening. Culture-based, there’s a lot of mentoring and learning happening. There is advantage knowledge sharing, but it’s only if I’m open to it. And if I’m very clear about what I want to get out of here, because if I want. Let’s say if I want to find it back, it would be the best to ask a person that’s familiar with the code to be on this code review and not, you know, a junior, but if I want to have this learning expect more in, in, you know, in the center, then obviously I ask somebody that maybe hasn’t seen that code part before, so that they get familiar, that I have knowledge dissemination that I have more people that are familiar about this code base. And I think most organizations. They’re not real bear. They, they hopped on this code review bag and because the hopped on, you know, to pull request, model to development and pull requests and code reviews are not the same. And so suddenly they wrote a pull request and they felt like, Oh, before I pull it in and look at the code and because I’m looking at the code, it’s already a code review. And so now I’m doing code reviews and I want all of these benefits without actually investing I’m investing. And then here it comes back to this slow down. Right. So I have to probably slow down first. Really find out with my team, what is it that we want to get out of code reviews? How are we structuring our processes, our practices, and this has to do a lot, right? Like, depending on the risk profile of this code review, who should be on the code review would ask for feedback, how long should it take them? What issues are they looking for? All of that can actually be designed and very deliberately made. And then you’re getting really a lot of benefits out. But if you’re not doing that, yeah. Then you’re in this state where. He just wanted, it looks good to me. Right? The other person knows you just want that, but still feel a little bit pressure, um, that they have to look at it because if it goes in, they’re also responsible. And so there’s this delay, um, and you don’t want to spend time for it, but you have to, you know, and then you having an, I actually have a, if you look on my website, there’s the code through your quadrant. Um, and this means like it’s, it’s, you have to access and it’s the speed of the process and the value. And this means that you often have them. Organizations that are slowing speed. And low in value. Right? So they are low in, in speed. They’re very slow. They’re bottlenecks and they don’t get value out or that they’re fight fast because they’re just giving out. Looks good to me, but they’re not getting value out of this. Right. But even if you’re waiting for look good to me, Like say half an hour or an hour or four hours, it’s still slowing down your process. And the question is, was it worth it right? If people are not really taking the time to review. So in the end for me, it was probably a very long answer to your question, but it really comes down to what, why do you do code reviews? Right. And do you have to have an answer for that? And probably depending on the code change, the risk profile of the code change and the code change, you will have different answers to that, or this code review. I want that, you know, my junior engineer knows how that works. And so I’m sending it over or this, this code changes about how we are doing the checkout. So I definitely want, you know, two more eyes, um, to make sure that there are no, no defects going out. Right?

liran:[00:23:47] Yeah. I mean, that sounds so complex. Can’t we just automate this and install some tool and get it over with.

michaela:[00:23:55] I definitely parts of it. And I think that a lot of people are, are, are doing stuff that tools should do for them. Right? So they, they, they are mocking on, you know, style issues they are talking about, you know, some, some things that actually study analysis tools could find. Um, or automated code review tools, whatever you want to call them. Uh, in the end it’s, it’s, linters that checkers steady analysis tools. Right. And they are actually much better than, than people. To find certain, certain errors and certain problems with your code, they can actually, you know, they can walk through your code and really find out, you know, if they’re, if, if some code paths are not called and tell you, Oh, this is actually not going to call it. Or, you know, really also back study analysis backs, but they are limited. So it’s, it’s not something, you know, they are not, you cannot comply, uh, replace the, the manual review. But you can replace a lot of that, you know, nitpicking, which is very unproductive and code reviews. Um, it doesn’t matter. Like why would you have an engineer spend time on finding certain types of errors? If a tool could do it automatically? I’m I’m all for automation. I think it’s so important to automate whatever you can automate here. Yeah. Are you using, are you using some automated tools in your pipeline?

liran:[00:25:15] So yeah, we actually adopted a GitHub advanced security. A few months ago at lookout. And it was actually a pretty good tool for us. It allowed us to gain some insights, actually both brought us a lot of insights into some of the other code that broke out and kind of knowing where we might’ve pitfalls, but it also managed ha ha is helping us moving forward, knowing that it could work coder pushing through discussed meeting there. No style checks and best practices, especially when it goes to more junior engineers or engineers or working in environments that are not a strength. Let’s say, I know most of our full stack engineers spend most of their days between a, you know, react and node JS, but occasionally they dive into Golang. And then all of a sudden, they’re not as fluent in, you know, what can go wrong and how should the code views. And some of those arrows can easily be caught by those automated static analysis tools. Also, it’s a very useful tool personally, we’ve, we’ve recently developed support for Ruby and surely within that skeleton of project, we started with Robocop, which is a very, very strict, eh, who bill inter. And that’s actually provided us with a lot of insight and kind of kept us very honest as we were developing the code, keeping functions, very short, creating a very orderly and well structured code. And that’s kind of something that it’s always a dilemma for me when starting a new project. Do you go ahead and spend a lot of time building the skeleton, building the CACD building, building linting. At the beginning of the, you wait for it later on, because you know that later on, doesn’t always get by. And if you’re adding a linter to an existing project, and then all of a sudden you’re getting, you know, dozens of errors, then you might not be, get going around to fix them because it’s too much work and that’s always kind of a dilemma. But for that project, it was a very good experience for us in developing high-quality code.

michaela:[00:27:25] Yeah, that’s really nice. Yeah. There’s also my experience. Like if you, if you add that to an already existing, quite substantial code base, right. It’s just out of hands, right. You will have like all these red flags, orange, whatever, you know, depending on the tool that you have, like different severities of issues. And I always feel really bad because. I know that I’m not going to be able, like to go back and, you know, redo the past. Um, you can do it slowly by slowly, right? Like I’ll voice called removal or at five by refactoring where you say, well, if I’m touching this code, I make it nice again or make it better and you can do it ongoing. Um, but yeah, I also feel like for, for existing code, it somehow has this, you failed here. Um, um, Psychological, uh, you know, by byproduct, but you’d be like, Oh, now I’m seeing what’s all messy and you cannot really do it. Um, yeah. But yeah, it’s good that it worked out. So apparently you could, could you remove all of the issues? Could you work through all of them?

liran:[00:28:26] So we got through, and I think 95% of them ere, there were some, a few areas where we decided that. That code is not going to be the nicest code in the project. And that’s okay. This code is mostly, you know, four, it wasn’t was low maintenance, low complexity, just a lot of, you know, lung functions doing boring stuff. And we said, that’s something we can live with without spending too much engineering efforts, kind of fixing it up and making it look the best.

michaela:[00:28:59] Yeah. So in the interview and the research interviews that I’m doing right now, we talk a lot about technical debt as well, and how people deal with technical debt. And I’m asking different organizations, different teams, their strategies for technical debt. What are your strategies? We have like some, you know, some amount per sprint that you can use on that, or how do you, how do you even. Um, assess the value of working on this, uh, you know, technical, then you were talking like, Oh, we already okay with this part of the code base, but how do you assess that? And on a more strategical, systematic level, right?

liran:[00:29:34] Yeah. So I guess that’s a two part question. And on the one part, we do have a strategy and I can talk about it a bit, but I think it goes beyond that. I found that for you, you mentioned actually early on that nothing in very literal in tech is factual and most of it is opinions. And I think that’s doubly true for a tech debt. And quite often one engineer joins a project and they decide that what’s happening. Much of, many of the decisions have been taken before they joined our tech that there have been wrong. And I would wager basic statement that it’s. Probably the other way around. I mean, if the project is live, if it’s generating value, if that piece of code was walking from when it was written up until now, then chances are the decision to, to do it. That way was actually correct. Or at least descent. And engineers often jump to say to, you know, define tech that because something is not in the latest design pattern or something is using an older technology or paradigm, or maybe simply because they don’t understand something. So often the first thing you have to do when you think of tech that is actually understand what’s going on and truly think for yourself. I truly think about it. Is this truly affected? Oh, is this something you lack an understanding? And actually that’s something we were seeing within Rueckert and with our customers that shook out is quite often used for once you have a better understanding of the code, because you can see how it’s working and you can see inside of it, then you quite often realize that’s not actually that that’s the, I just didn’t understand how it was working. And once you get gain a better picture of how is it working, why is it working that way? And none of the sudden then it makes perfect sense. But obviously sometimes there is real product that there is real tech that they, for the most part, we kind of manage tech debt on a, you know, quarterly on a quarterly roadmap. We have a very. Agile flexible quarterly roadmap while we manage our roadmap, eh, usual, all the rollout. And you also kind of add, you know, a handful of tasks for each team and full of mid-level mid large tasks for each team where they can, whether they should strive for a tech that. And obviously, you know, like that usually comes last in priorities priorities. So it doesn’t always get executed a lot. Depends on the roadmap progress in general and especially on a. Eh, eh, new tasks that get pushed in from the sales team as well, working with customers. And there are always new requirements for improving performance, for a meeting new criteria for giving the best experience with possibly can for our customers. And those often override some of other stuff we have on the roadmap, but we do try to get at least some of the tech that cleared every quarter, just to get a few low hanging fruits with high impact stuff. That’s been bothering us, that’s bothering the team. And also we find that having those, you know, tasks in the queue engineers kind of find time in way to get to them, to get it out of the way.

michaela:[00:32:56] Yeah. So what, what reminds me and what I wanted to ask you in that context is that the original or one of the very early on definitions of tech dad was code that didn’t have tests right from my Confederacy would say, well, it’s tech that if you don’t have tests, because then you really have a hard time refactoring and often, you know, There’s also this new, I was actually, I did a podcast with him, uh, recently on, on, on my podcast and we were talking about it and then he, and he also sat like tech tech. That is the code that has been outlived, but a person that. Wrote it right. And that in our days in our, in our, um, very fast pace or, you know, um, take industry where people will stay two years, maybe at the company, they write code and they actually never really see it in the maintainance pace. Right. So do you see it when they’re writing it? Maybe when you’re releasing it. And so a lot of the, you know, like a lot of the, the. Code becomes tech deck, because the knowledge is actually gone from the organization that, you know, wrote that that code or, you know, can maintain or understand it. What’s your perspective on that?

liran:[00:34:07] So there’s actually a truck out we’ve kind of we’ve wrote and talked a lot about understandability. It’s exactly what you mentioned. It’s about knowledge it’s about if you’re able to understand the software, the code fairly well, then. You’re the new C you can do a lot. I mean, you can get stuff done. I mean, I think the most obvious example of that is, you know, those simple exercises you get on introduction to computer sciences file from disk, Salton array, eh, those kinds of stuff. And you know, those exercises you can usually do right now as a senior engineer in 10 minutes, 20 minutes. And you’re done, but if you were to get the same task within the context of a very large system, especially one you’re not intimately familiar with, then all of the sudden the same tasks can take you weeks. And then you’re going to start complaining about tech debt and lack of knowledge and documentation. And if at the same time, or to give that same task to the two, a person who was one of the founding team of that system, they’re still going to get it done in, I know maybe not 10 minutes, but 30 minutes. And preserving knowledge is super critical. And at the same time, we need better tooling. We need better tooling that would allow us to work with systems that are complex, that we’re not intimately familiar with. Obviously testing is there, as you mentioned, testing is a form of tech that because testing is a Godwin. That allows it to operate in a, in an area where you’re not familiar with. It allows you to easily debug the code that I, you to see it in action. Even though it’s a developing environment, you can see the code running, you could see it in action. You can make changes in a control mirror. We know what you’re changing, you know what you’re going to impact, but that’s at the same time, I think tests can be incredibly expensive. Even more so if you’re not already familiar with the code, so it’s kind of, you know, a conundrum you’re saying the code is not very good because it’s effective because it doesn’t have any tests and it doesn’t understand it, but then it’s going to be very hard for you to add tests to the code. You’re not honest. You don’t understand. I think observability tools, by the way, can provide you with some insights into how the code is walking. Right. Eh, but at the end of the day, nothing beats just debugging the code, stepping through it, see what, see the actual types and values of variables, seeing the inputs and outputs of the system and seeing it in action. That’s the best way to understand the code.

michaela:[00:36:45] Yeah. I think the too, when I was at the university of Victoria in Canada, um, I was doing a research as a bicycle there. And they, they developed a tool. I think at that point was called driver. You will not find it because it was a research tool, right. Not really popular and bad. The tool itself was really cool because it helped you understand cold. Um, my, my research area was called comprehension. And so really helping teams and engineers understand code. And so this tool was made in a way that you could Deepak and it showed, you know, the traces and the values as you just described. Right. But this is like, 15 years back pretty long time. So it was very novel at that point. Right. And so this was really used to understand coach. I think debugging is definitely one of the ways how we understand code, right. That we really go through it and try to understand what’s going on a really interesting resource maybe in that, um, in that regard is also a book that’s coming out from a friend of mine, for the Hermanns it’s called. The program has brain and it talks a lot about cognitive load and code reading. Um, there’s actually a workshop that I’m going to attend today about code reading, um, from her. And, um, yeah, and I think this is really, this is really interesting because it again goes into these different versions of cognitive load and also confusion that you have with code and confusion can come, come from different sources. One is lack. Of your own knowledge, right? So being a junior or, you know, being a senior engineer, you have a different knowledge base. So you can actually go back to your longterm memory and quickly access how to load the file, or you know, how to save a file, how to close a file and so on. And then as a junior, you have to really think actively think about this with means that you’re. Your, your processing power more or less, right? It’s reduced because you have activity after actively think about this. And we can think around four to seven things. So if you’re already thinking about those things, you know, there are only two more things that you can add. And as a senior example, you, you. You have that in your long-term memory. So you have seven things that you can think about. And the interesting aspect here is also the same with what you said about the code base. If I’m familiar with the code base, I can load parts of that from my long-term memory. And I don’t have to use my short term memory. I don’t have to use the processor for that. Right. Um, and so there’s definitely, there’s exactly what you’re seeing here. Um, maybe something else that I want to add here is you said knowledge dissemination. And code reviews are really good for that. Right? So that’s why I’m saying the organization has to understand the benefits as a whole, right? And suddenly if you understand that, well, if I can actually have, have a, a larger part of my team, be more familiar with a larger part of the code base, that’s actually extremely valuable and it will. You know, it will speed up your development process quite a bit. And there are also studies on that around code reviews where we really see that, um, it teams that have code reviews in place. They already have a Vitor understanding of the code base than teams that don’t have. Right. They’re only known only know what they’re working on. Um, and so why it’s slowing you down to do the reviews. It really speeds you up. Once you have to work in this pace, right. Or in this place off the copies, or if somebody leaves, you have other engineers that are also familiar with. With that. And so I think there are other benefits that are really, really, um, really important here. Yeah.

liran:[00:40:19] Yeah. I mean, I’m hearing here speak, it’s obvious. You’re an advocate of code reviews and you’re passionate about it and you’re making great, great arguments about why it’s so important and how the part, the value fit. But don’t people ever come to you and say, I don’t know, it’s slowing me down. It’s making stuff complex. I mean, I don’t want to do pull quest. I don’t want to do code reviews. I just want to skip the whole things and kind of what do you send them?

michaela:[00:40:50] So, honestly, I don’t, I don’t have a lot of people that have this complete mindset. I have a lot of people that would say I really would like to skip code reviews because I don’t have time to do them because my reward system around my recognition and what I’m expected to do is something completely else. And then I have to look at code reviews and, and this is not part of it. Right. So I recall one person, I was just talking with them. Like we could go around that. Right. It was part of the research again, and they were talking about it. How, how is it? It’s really difficult. They actually laugh code reviews and they learn quite a lot and they would have much more, um, much more benefit and would feel better about them. If this would be actively part of their job description and their expectations. But it’s in very many, many organization. It’s. It’s window dressing. It’s like, yeah, we want you to do code reviews and it’s really mandatory and they have to do them. But on the other hand, there is no time to actually do them. Right. And I think that’s, that’s what I see very often. I definitely see people that haven’t had good experience with code reviews that don’t maybe see the benefits out of that. But I also have, on the other hand, I think this is why I’m such a strong advocate for that. I have people, really, a lot of people that have seen the benefits and that have done code reviews in the right way. And, and, you know, with good processes around and with a good culture around that, that they say I would never, ever work anywhere else without code reviews, because it’s a, it’s a mentoring tool. It’s a learning tool. I’m learning so much more. I’m so connected to my team. Right. And not working in a silo anymore, but this needs a certain time of code reviews. You cannot like work on a feature for a month and then throw over like thousands of lines of code or whatever volunteers look at it and give me feedback, right? Like this is not gonna work, right. This is, uh, this is definitely a frustrating experience for everybody. And in this case, I say, get rid of it. You’re not getting anything out of it other than frustration. Um, but also be honest to yourself that you’re actually not really doing code reviews, right? You’re throwing pieces of understandable codes to somebody else that can spend maybe half an hour, an hour to look through thousand lines of code. What are they going to say to you? Nothing. Right. And so maybe it’s really to be about, be honest and say, if I want that, I need to slow down, understand how to design the process. Um, maybe even get help for doing that. Right. And then, and then really do it right. And have so many people that really love code reviews and so many teams that are striving through that. Um, and yeah, so definitely if you know, if they don’t bring any value, then it’s really, I think it’s very often the process that’s just completely screwed up and the culture around it.

liran:[00:43:39] Yeah. And do you find that companies struggled to understand which public was deserved called the abuse versus which, what policies did they have in place to know to solve them out? Sometimes I know sometimes just adding a log line and then you need to go through the same code of your process, or at least by definition, it’s the same workflow as if you’re adding a big feature. So kind of how the companies go around managing the different kind of pollute quests.

michaela:[00:44:08] So I think this is really a part of, I cannot generalize, um, because for some organization it’s definitely valuable to go. Through a pull request or a code review for every line of code that they’re doing, even if it’s a lock line. Right. Um, but then this is a certain type of company and they have certain goals around it and it’s beneficial. I definitely see also, um, you know, organizations that have some code review guidelines in place and it says we have to look at every line and it’s a log line. It makes no sense here. Um, very often here, people haven’t thought about again, you know, what are our goals with cultural views? And if you think about the goals and it’s a logline in, you know, Yvette Yvette site that I can update within minutes because I have a fast pipeline, why would I go through a code review here? Right? Why would I slow that down? What’s the benefit here? Um, so I think that organizations that are more vague about their contribution to practices and process, and really take the time they understand that. Um, and it has to do with risk profiles. Can engineers, do they have like guidelines to work around? Have we thought about this as an engineering team? What are our values? Um, when I was working with Microsoft, we had like, there were, there’s not one code review. Policy, right. It really depends. Office has a different policy than windows. And then even in, in office, you have like different teams that have different policies and so on. And so the teams really thought about, um, some teams would say, well, for us, every line is reviewed. And then other teams would say, uh, well, vs keeping, for example, refactorings if you do a refactoring and you can show it, it’s, uh, uh, And refactoring that has no side effects, then you can just put it in or some teams would do the review after they’ve pushed it, for example. Right. So after, after committed, after pushing and after merging, they’re doing the so. The, the policies really differ. And I’m not saying that, you know, even if the differ for some teams, they were really good for some teams do or not. Um, it really depends how, how honest and how in there and reflected people were around their cultural views. Um, but you can definitely be design and, you know, even have automatic things that help you to decide whether or not something should have a code review. Right. You could buy somebody if you think about conventional commits. Where you have certain aspects in the commit message even right? Even those systems are in place. If you, that you could do here, where it could incorporate some of the risk of something, or you have against that again, as it tools around somehow assess the risk. And that helps you to decide whether or not you need a code review or in what depth you need a code review here, how many people should be under code review. Right. So, so many questions, uh, yeah. Yeah. Touch on what you meant.

liran:[00:47:07] Uh, that’s. Exactly. Yeah. That’s that’s perfect. I think we’re almost running out of time here. So maybe Mo join us, throwing a few questions

michaela:[00:47:16] from the audience.

maror:[00:47:17] Okay. So actually, a few questions did come up. If you guys are ready for it, um, McKayla, we’ll start with you. Can peer programming, replace code

michaela:[00:47:26] reviews. Okay. Um, pair programming. So I, yeah, this is a, this is a very often, uh, asked question and my answer is no, it’s very similar to, you know, can automated contributes, replaced code reviews. I think they are very complimentary here again. So if you have peer programming, um, You’d probably have different cultural view practices again. Right. So very often we talk about code reviews and then code reviews are that thing that everybody does the same, which is completely not true, could be, it can be so many things, right. If I’m looking over the shoulder with somebody and looking at the code at the same time, it’s an over shoulder over the shoulder code review. And so peer programming could actually be one kind of code review, but then you have to ask your, you know, for yourself or your organization again, Do we need more? Do we need like some gatekeeping around that so that we have another person do we need in fairness right around that? If I have two people that are pairing very often, then you have like this knowledge silo, again, that those two people know about the code, but maybe I want other people in that, so we’ll add them. So, um, code review can be, uh, a complimentary strategy to pairing, but I definitely say it should look different, right? For team, the task pairing code review should look different than for a team that desk. Does know Perry. Yeah. Okay.

maror:[00:48:50] Very cool. Um, Leon, I think this one’s for you, what’s the relevance of code reviews for compliance.

liran:[00:48:58] So I think we found that there are a few, few key elements in that I think compliance kind of often requires that, eh, some peer reviews, every change, and I think it goes back to what said about the purpose of code reviews. And compliance for the most part would be focusing on first and foremost general security review, but even more. So it’s an often a question of trust and governance that you essentially know what code is going into the system in a way. I think it’s very different from most of America is been talking about today, about, you know, in depth review, understanding the code and. Eh, me ensuring that you have all the right pieces in place. It’s more about cursory examination that you make sure that you’re not, you’re not changing anything. You shouldn’t be changing that the person is making that commit within the assigned task is working on and within the assigned scope, if there are any changes to security, sensitive area that you go through additional scrutiny. But if those are eh, you know, It’s more about ensuring that whoever is made the task, did what he was supposed to do rather than the quality of the work he did. So that’s a very different thing. And it’s very important again, to kind of. Define the purpose of the code review. Is it just about understanding the scope of the task and the scope of the change, or is it about deeply evaluating it? Giving feedback, mentoring, sharing, knowledge and so on and so forth.

michaela:[00:50:43] Okay.

maror:[00:50:44] Um, and Mikayla, if people wanted to learn more about code reviews, where, where would they be able to

michaela:[00:50:50] go to do that? Okay. Yeah. Um, obviously I can see my website, right? I’m writing quite a bit about code reviews, which would be awesome. Code reviews.com. Or you can also go through my, my link. That’s my name, Kayla gala.com, which is a little bit more difficult for me. We can put it somewhere, but I’m awesome. Code reviews, dot com should have them work as well. And, um, yeah, I also have like a GitHub. A project that’s about code reviews, um, where I’m listing a lot of different resources that I find on the web. So it’s not only from me, but also what I started recently doing is best practices from different organizations. So there are articles where you see like how, um, You know, for example, the Google desk cultivators, or how is, you know, VMware doing code reviews and other, um, resources that I found really valuable as well. I also have like code review checklist there on my guitar profile. Um, so it it’s, uh, the guitar thing. And then my, my handle is M and then Kyla, G R E I L E R. And so, yeah, there, you can find also quite some stuff, um, that, um, that comes from everywhere that I found this valuable.

maror:[00:52:03] That is a wealth of information that everyone should definitely take advantage of. Um, and I will make sure to send out your Twitter handle for them too, so they get it. Um, and on the topic of learning more in the event, where can you learn more

michaela:[00:52:17] about lookout?

liran:[00:52:19] So you can learn more about first and foremost, that’s roka.com, which is our awesome website. We’ve just launched a new website. And so feel free to check it out. Also, you can reach out to me on Twitter at
other school last, and I’ll be happy to chat with you and share more about what

michaela:[00:52:36] we’re doing.

maror:[00:52:39] Amazing. Okay. So then we have one last question here, um, and it looks McKayla like it’s for you. The question is, do we need additional manual reviews or testing if we have a study analysis tools or is

michaela:[00:52:52] that enough? Okay. Um, I think I touched it a little bit on that. So I definitely think it’s complimentary again. Right. So if you have, like, I definitely recommend to have studying analysis, test tools, have static analysis tools, security tools, because they are much more systematic and they they’re defining more issues. They are less error prone. You’re not overlooking something, right. Especially for things that are systematic. As I said, Um, for example, security testing tools are really good or, you know, security analysis tools are really good for injection box, um, where, you know, people would have a hard time and it’s just unproductive for them to look at that. Um, you know, in, in the, in terms of what a tool could do here, but then for example, broken off, um, authentication or just the flow of things that is really beyond the scope of tools right now. Right. So if you’re, for example, sending out. Let’s say that you’re somebody is requesting a password reset, right? So the whole, uh, workflows through dat can be very, very broken and there are no tools that, right. An alpha example can check for that. So that definitely has to be done manually by, by person and very similar in the cultural sense. Right. So, um, there are really good static analysis tools, but there’s always things that just the tool cannot do for you. So they are complimentary, I would say. Okay,

maror:[00:54:18] thanks. So that’s all we have time for today, unfortunately. Um, but hopefully we can also down again cause it’s been great. Um, so thank you everyone for joining us, we will be sending a follow-up email with the recording and McKayla and Leon’s contact information for whoever wants to get in touch with them. And thank you McKayla. And thank you again.

michaela:[00:54:38] Yeah. Thank you so much. Let’s refund.

liran:[00:54:41] Thank you. Thank you.

Book your awesomecodereview.com workshop! Secure Code Review Workshops are coming soon too!

Episode 38: Legacy code and what to do with it – With Michael Feathers

In this episode, I talk to Michael Feathers. Michael is the author of the super-popular book “working effectively with legacy code”. He is also the founder and director of R7K Research and Conveyance, a company that helps engineering teams with their software and organization design. Recently, Michael also joined Globant as Chief Architect.

We talk about:

  • legacy code and how to deal with it
  • how systems almost feel like living organisms
  • how we are on a journey with our code, and why it’s so important to care for it,
  • how legacy code is the result of an organization where engineers turn faster (leave the company/team) than the code churns.

Today’s episode is sponsored by Botany.io – Botany is a virtual coach for software engineers that unblocks essential teamwork and levels up careers!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: Legacy code is a living organism – With Michael Feathers

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: [00:00:00] Hello and welcome to the Software Engineering Unlocked podcast. I’m your host, Dr. McKayla and today I have the pleasure to talk to Michael Feathers.

Michael is the author of the super popular book “working effectively with legacy code”. He’s also the founder and director of
7K Research & conveyance, a company that helps engineering teams with the software on organization design.

Recently, Michael joined Global as a chief architect. Since I have been at university reading his amazing book, I always wanted to pick his brain. So I’m super excited to have Michael here with me today. Michael, welcome to the show.

Michael Feathers: So glad to be here.

Michaela: Yeah, it’s my pleasure. I’m really, really excited. Michael, you have been probably working more than 20 years with engineers, with software companies from all over the world. This is so, so fascinating to me. I’m super curious about how different organizations develop software. I’m always asking the questions. What makes teams and organization more effective than others? What’s up engineering practices. Do we have, I’m a big fan of code reviews. And so I want to know from your experience, are there best practices? Can you make out best practices that really lead to success for engineering teams where you say, well, if they follow that, right, they will be very successful versus factors that you think they are definitely bad and lead to a lot of troubles.

Michael Feathers:[00:01:23] The question. And it’s interesting too, because like the practice space is very interesting, but I think a lot of it really comes down to organizational culture, you know? And it’s, you know, if you have a good culture, then basically like the practices will develop almost invariably, right. Or you’ll at least be open to going in and exploring different practices and things along those lines. I think, you know, for the thing that I have gotten called into organizations for quite often, you know, legacy code, the thing I kind of noticed over and over again is that. What is missing sometimes is really a very Frank conversation about the quality of the stuff that people are working on. Right. And in the worst cases, it’s kind of like a. It’s like everybody is told, you know, you must write code and you must design this thing and create it, but nobody’s really paying attention to it. And sort of like, you know, thinking about it as being significant, you know, quite often there’s like a task focus rather than focusing on the quality of the thing that you’re producing, that kind of thing. So I, you know, I wouldn’t really know how to go and actually sort of say, what are the best practices? I think that so many of the things that we basically do. In the industry now regarding testing and pairing and mobbing and you know, the way that we allocate work and stuff like that, a lot of those things really kind of help. So.

Michaela:: [00:02:38] Yeah. So one thing that I thought about is engineering values versus practices, right? So I think that engineering values and developing dos is a team. And not a lot of people are talking about it. Unfortunately I think much more people should talk about values. The engineering values that we have. And not the practices because practices can change and they should change. Right. They should change over time. And with technology changes and with our, how our society changes, the practices should change and somebody comes out and has a new idea. Right. And th they try something, they fail maybe 10 times, and then suddenly they found a new thing. . But the values, I think, for example, what about our. Code health. Right? I wanted the quality of the code that we are expecting how we are developing software, how we are talking about the things I think those values are really important. Is that something that you have more and more teams do or, you know, successful teams do.

Michael Feathers:[00:03:28] Yeah, definitely. I think it’s yeah, it’s a lot of, it really comes down to taking the work seriously. I think, you know, in a way, and in terms of values, it’s, it’s, it’s funny with this too, because you know, there are many different, like, you know May different ways. We can look at, you know, values across organizations and different frames we can use. But I think that actually going and seeing the systems themselves as valuable is like a rather important thing to do as well. Right. And that’s a little piece that tends to be missing at times. One things that’s kind of been striking to me across. You know, my career is basically noticing that in the very beginning back in the 1990s, it seemed like there was this thing of kind of like, well, we’re all kind of like disposable and as engineers, you’re just basically there just to do the work and then basically go home or go bowling or whatever it is you want to do in the evenings. Right. So going and recognizing that we can become more whole people at work and basically valuing our own development and valuing our communication, our relations with our coworkers. And I think that’s a great thing, but then there’s also this other thing too, of like valuing the thing that we do and looking at the things that we create as being significant and having their own intrinsic qualities that we can kind of like, you know pay attention to and kind of foster over time. So yeah, I think one of the things I’ve been coming back to over and over again within my career is just this notion of thinking about the systems that we create as if they were like alive in a way. Right. And we get to care about them. Right. And it’s kind of like this way of going, like applying like this anthropomorphic frame to the things that we’re working with. And some people might say, well, that isn’t like a it isn’t like a good thing or it isn’t a realistic thing, but I find it very useful to come and sort of think of them. Think of the systems we work of is basically things that we can foster and care for. You know, I think that helps us become better engineers.

Michaela:: [00:05:17] When I was preparing for this interview, I read through the things that you write on your website on the RS seven K website. And this is something that I read. I was really fascinated by it. Like. That the code is in living organism. Right. Sort of, and, and I thought, well, this, this is true. Right. It evolves, it changes. People come in and the levels are their think of Prince there. Right? So coded I right. Looks probably quite different than code that you write. And even if you have engineering values around that, and even if you have coding standards, you probably can tell, you know, sometimes the boundaries of this is where one engineering team or engineer work. Then this is where another engineering team works. And you also talked about your, how actually Cultures and the organizational structure shape our code, which is one of those laws that we have been seeing and studying for for many years. Right. Where we see that actually. Yeah, exactly. Right. But you see that you have the organization and the boundaries and how you structure and the design, your organization will reflect in the architecture of the system, which also shows that somehow it’s, it’s living with the organization and growing and, you know, Aging and getting to a legacy when the, also the structures of the organization change. And it probably it’s even harder to change the code per se, when you’re changing the organization. Right. So people change organizations all the time. They’re reorgs in large organization. They’re reorgs all the time, but we’re not reordering the code in the same capacity. . So what is your thought on that, especially about technical debt, for example, Then he called that, that cumulates over time. How should we deal with that? And how should we integrate that in our day to day work life?

Michael Feathers:[00:07:01] The, the main thing I keep coming back to us, like the frame. For this, you know, it’s kind of funny. We can talk about this being like a metaphor that basically code is like biology, but I think just about anything that kind of grows incrementally, where it’s easier to add new things than to change existing things tends to go and sort of have like these hallmarks of organic growth in a way. Right? Like I used to say to people, like, if you, if there’s like a young tree and you kind of like kick it and it kind of like falls over a little bit, it’s kind of like, it’s not going to upright itself. It’s going to basically continue to grow. You know, upward, but from the direction you kicked it out. Right. And in much the same way that kind of thing happens with our code is that the things that we do tend to basically leave their Mark upon the structure of the code. Sometimes in complexity theory, this is called path dependence. It’s kind of like that basically. You’re dealing with something that has a memory and basically what’s possible with it depends upon what happened previously. Right. So I think that the main thing is to kind of like, just sort of like recognize this, recognize that that this is part of the character of, of code itself and that we don’t really ever get to go and sort of like say I’m going to build a brand new system. Like the complete rewrite, that’s going to go and be shiny and, and perfect. You know, that’s going to go and serve. I solve all of our problems that, you know, the, the code that we create, basically we’re on a journey with it and it’s going to basically take time for it to go and react to the new situations in this environment. And those new situations are how our organization is structured. What new features we need within the system. And it’s just going to be like this slow process of change. I think the interesting thing with this in terms of practicality is that. It does mean that sometimes it’s easier to go and create new systems than to go and sort of modify existing ones. And we should be a bit more proactive about doing that. Sometimes we’re basically like you know, if we have particular products and an organization think about creating new products sometimes rather than trying to burden existing products with new features that may not quite fit for instance. So, you know, that’s. It’s a rather abstract answer. I’m sorry, but it’s kind of like, you know, I think that basically this frame that we have of looking at software in this way can help us make some of these decisions a bit better, but they don’t like sort of solve all the problems necessarily in there.

Michaela:: [00:09:21] I heard you say a couple of things, especially before where you said, well, we have to take the quality of the system more seriously. We, you know, we have to be more careful. In my experience. I see, I see several camps, right? So there are the, really the, the engineers that, you know, they love high quality code. They, they learned a lot about how to create high quality code and they really do and nurture the systems quite a bit. Then you have like some tension between business goals here because as long as it works right, and it fits the business goal, there’s like this tension and this, this pull towards, well it’s good enough. Let it. Be please don’t make it nicer or more elegant and more inspiring. Just let it work. And then you have also very pragmatic developers that are maybe, you know, they’re not, they’re not into elegant code so much. I haven’t seen many of those, but they are. And I think a lot of more people become, especially like people that are creating software because they want to create something, right. They want to do products. So we have like a new wave of engineers. I think, especially when I studied a lot of people studied really for software engineering, but they were not entrepreneurs. Are, are only a couple of them were right. And now I see there’s like a huge mass of people that are also. Engineers, because they want to be entrepreneurs. They want to create products. And I think they’re coming a little bit with a different mindset into the whole you know, why are we using code and using code and code is just a means to an end, whereby I don’t know when, when I was in university, it was not a means to an end. It was the end, right? Like, this is why we are here. This is, it was not, it was a product focused. I had not. Lecture about product. I had only lectures about code and what is good code and what are good, you know development practices. And I also studied computer science. So a lot of computer and computer systems and system architecture and so on. But no product, right there was not all, how do we position that product or what makes a good product, not even product management, which probably should be there with it anyway. So I’m saying. I think there are more people now with a more pragmatic view on software than maybe 10 years ago. That’s at least my experience. So how do we balance that? And is that a good thing? You know, is it a bad thing? Can we even say, you know, it’s good or bad? Is it binary?

Michael Feathers:[00:11:46] Yeah, we can, we can basically have like a very instrumental view of code and systems and say they’re there. To serve us. Right. And that’s a frame, which like you say, can basically help you out if you’re an entrepreneur. And you’re just trying to get something to market very quickly. But you know, it’s a story which is, you know, just, you know, an age old story that essentially it’s like people get to market and then they discover they can’t change anything because they’ve created such a brutal system that it’s impossible to work with. So you’re always going to have like a mix of people they’re pragmatic and people that are idealistic, I guess, the. The important thing culturally is getting them to be able to talk to each other and see each other’s point of view and recognize that sometimes you have to be in it for the long haul and you have to be able to make trade-offs that sometimes it’s good to be opportunistic and do something very quick and dirty and disposable. And other times you want to go in like really invest in a particular thing, because it’s important to you. One thing that is weird about this is that I think. If we look at code as being just this mechanical thing or this thing, which is like over there someplace, or the thing that we mess with, you know, when in between our business conversations, which are really more important, you know, then we we aren’t paying attention to it enough. To basically understand when it can get in our way sometimes. There’s a guy I know Colin Brecht who basically started doing this thing called quality views. So it’s an idea that I had years ago and he was doing this within his organization and it’s a really, really cool tool for going in, dealing with technical debt. And I really want, that’s a great thing to go and talk about. It seems like with technical debt, we always go and we ask like the business side for like, Time to go and like go back and fix things. Right. And it’s kind of like, that’s always like a tough sell and it’s also kind of like people say, what am I going to get for that? Right. But the technique around this is to go and say, let’s take a look at our systems. And kind of like make a little pictorial representation of that. Maybe like if you have a big system, maybe it’s like five boxes of things, right. And then when we’re discussing the features, we want to add to the system, we can go and say, okay, well this particular feature touches these three boxes and this other one touches these two boxes. And what you do is you put colors on these boxes to indicate their level of health. Okay. And what happens is that color gradation is going to change over time. Right. And you just basically don’t use that as a basis for conversation with the people who aren’t looking at the code all day. Right. And the neat thing about this is that without talking about technical debt at all, it starts to become like this feeling within the system, within the organization that, you know, the code is a real thing and it has a particular qualities. And those things can either help us or get in the way, depending on how healthy it happens to be. Right. So it’s not uncommon to go and do this and have somebody go and say, gee, you know, this one area of the system is very red and it seems like every time we ask for features to touch this area, you know, it’s going to take a long time. Can we do anything about that? And then you actually have the business going and asking for system’s health. . Whereas before it would be completely invisible to them. . So I think that stuff like this is kind of like the path forward in a way is to basically sort of make. The systems are real to people within an organization. And, you know, sometimes the choice is going to be to do something very pragmatic that might actually go and sort of hurt things for a period of time temporarily. And you might just need to do that for the business, but you’ll at least understand what the consequences are of longer term.

Michaela:: [00:15:07] Yeah. I liked that. I liked that idea a lot, because if you think about a business and it has a building and it is in the building, like, and the building just rots right. Buildings wrong. Right. So they. They get older. The forsake is not nice anymore. The entrance is maybe not nice the floor, right. Ceiling and so on, but people it’s very visible to people and you think like, well, it’s good enough still it’s good enough. But there comes a point where you think, well, we cannot have this entrance. It’s still functioning. Right. It opens the door, but it makes them noise. Right. And it looks horrible. So you don’t want to Valcom your, your people there and, you know, At one point, there is no, you know, no way back to repair it, right? So then you have a big disaster, but this is very visible. So I liked this idea that you actually, you show it, you help people imagine what actually the system looks like, right? So there’s some visibility and transparency in it, which I think is very often missing. And I think that this, this missing visibility and transparency is also something that makes our, our lives so hard as engineers. Right? We are in front of the computer.

Michael Feathers:[00:16:10] It’s completely invisible to people. Right. All they see is people looking at monitors and it’s like, who, you know, they look at us looking at monitors and they’re like, Oh, what are these people looking at? Right. So it’s rough.

Michaela:: [00:16:20] And, and you also, you don’t see, the work and the quality of the work. Right. Do you see a button and one engineer can create a button and another engineer can create a button, but you don’t see what’s behind it. You know, like how is the backend integrated? Is that button actually really usable for another button? The CSS come, you know, from a class or is it just. Do you know, hand drawn into in, in lane style or something, right.

Michael Feathers:[00:16:41] I think it’s almost it’s beyond metaphor in a way, is that I think it really is true that software’s physical in a way, you know, it really is. Now, when you think about object orientation, it’s like objects are meant to represent things or to basically be things that, you know, have cohesion and coupling and can communicate with other things. You know, all of these things live in this virtual space, but it’s like they still. Obey some laws of physics in a way it’s kind of like modularity is like when something grows too big to basically fit in our heads, we basically want to keep it smaller. Right? So you can see that as being just like objects in the world. Some things are just ungraspable because they’re so huge and software can be like that too. So we want to go and keep it smaller like that. So I think, you know, we can use the real world as like a decent, you know, framing device for going and understanding these things and helping us make better decisions.

Michaela:: [00:17:32] Yeah. So I’m interviewing and talking to a lot of people right now, engineers, and I’m talking a lot about, you know, their values and also the code based health and what makes them happy, what makes them productive. And one thing that I hear over and over, and again, is that. You know, you have your engineering heart, right. So good code, good quality makes you happy. That’s definitely something that I see for, for many, many people, not everybody, but a lot of engineers, but then you have all these system constraints and now the system is an organization, right? So you also have, you have to fulfill. Your duties, you have to do what you’re supposed to do, and knowing that you’re doing what you’re supposed to do, it makes you also happy. It makes you more excited. Right? So if you know that you’re actually working on something that you’re not supposed to work on, it makes you unhappy. And, and it’s also risky to take on the task, right? So there’s this, there’s this productivity then there’s this code health and they’re all some how intertwined. Right? So people want to work on, for example, technical death is something that people, a lot of engineers would say. Well, it’s a challenging problem. I like to tinker with Dakota, like to make it nicer. I like to make it more, you know, reusable, more maintainable and so on. But on the other hand, there is business constraints and business needs. And my manager, you know regards me, or also evaluates me based on the features that I’m delivering. So I actually cannot take on. Technical debt. And very often I hear also people talk about the commitment is too big, right? So it’s not only that it’s a single engineer that cannot take on the technical debt. Even the team mission is not aligned with, you know, getting rid of technical SRE. They will work a little bit on technical debt a little bit here, but then the. They’re getting more, accumulating, more technical that overall. So they are actually not, you know, they don’t feel that they can really do a big thing. And I think you probably people will call you when there is like, when you have a problem. Right. So it’s too far. So how are you going to change the mindset? How you’re going to work with the people?

Michael Feathers:[00:19:32] People usually call me once they recognize that they actually have a problem, you know?

Michaela:: [00:19:36] Yeah, it’s very late, right?

Michael Feathers:[00:19:37] And I think that’s the bigger thing too, is just as developers, when we’re working in an organization, it’s a bit of work to go and actually go and convince people that actually some investments in going reducing technical debt gives you a payoff. Right. I think the most important thing to go and recognize this, that like there’s almost like this 80 20 rule that basically goes and happens with code change. And I, you know, I haven’t really seen research around this, but it seems to ring true. Maybe you have, I know you have a. We have a research background, but it seems like there are hot spots in code systems where basically there a lot of change tends to gravitate towards them. They can shift over time. Right. So the thing is, it’s kind of like as a developer, if you’re going and looking at something that’s pretty messy and then you look back and you basically see that that area had like, Thousands of commits made against it. One thing is you can pretty much count on us, any little thing that you do to go and make things better. There is probably going to go and give you a bit of a payoff, you know, going forward because of the fact that it’s a hot area of the system that goes and gets a lot of change, right. And I’m getting, you know, in the organization, just, you know, we should never look at technical debt as being like this thing, which is a uniform across an entire code base. I mean, it is in a way, but it’s like in terms of the value of technical debt, It’s wildly different in different areas of the code. Some areas are more mission critical in your code base than others are. And if you can at least have different say, rules of engagement for the system and go and say, you know, we know we don’t have very much time, but you know what, whenever we touch this particular part of the system, we’re going to be really careful about this. And we removed. Technical debt because we know that it’s critical for our business and we’ve changed it a lot. Just getting simple agreements about that, going forward, give you almost like a bit of a foot in the door in your organization to go and have this conversations about how quality impacts things. So yeah, it’s never like this thing of like, Hey, let’s go install technical debt. It’s more like let’s find out where it really pays off and then go and use that as a way of going in sort of like surfacing the conversation and doing something about it. Cause that’s gonna be a smaller investment.

Michaela:: [00:21:36] Yeah, hotspots is definitely something that we saw in many different empirical studies as well. Right. So that problems accumulate in different areas more than others. And there’s clusters that around that and so on. So it is definitely. Rings true for me from, from this perspective as well. And I like what you said, well, technical debt, you don’t have to work on every technical debt unit code base. Right? Some of that, it doesn’t even interest you because you’re not touching it. The system runs, there’s not, I think a lot of much it backs you has to do with how often you’re changing the parts, that there is a lot of technical debt, right. So if you’re not changing the parts who cares, right. Probably I don’t

Michael Feathers:[00:22:17] And, and really, I think, I think that’s one of the things I like in my book. I talked about this a bit in terms of writing tests, like going and breaking dependencies and writing tests for particular areas of the system is that because there’s this kind of like power lodge, predo distribution of code change that if you take the time to break dependencies around a huge class and write tests for it, chances are, you know, you’re going to come back to that relatively soon and basically go ahead and discover that that work has already that hard work has been done. And you’re going to be able to take the benefit of that work. Right. So it’s kind of like, it’s, it’s weird because like that power Lalish growth goes and leads to some chaos and systems, but it would also helps us in terms of going and sort of focusing our, when we focus our energy, we get payback for it also. So it’s like a place where we get a virtuous cycle that goes into Alliance with the psychotic cost of the problem, you know, so we can sort of. Leverage it to go and solve the problem as well. Like, I’m not sure I can put words better yet, but.

Michaela:: [00:23:15] No, it sounds, it sounds good. Yeah. . So you were talking about testing and in your book, and this was also a good question and it was actually asked on Twitter, right? And your book, there was this really strong connection with legacy code and the. Lack of tests, for example, because if you don’t have tests, tests, somehow are also a means to an end. Right? Did they give you confidence that when you are making changes, the system is still very similar to what work, what it was before, right? So you’re not introducing anything. Box, hopefully. Right. And so the better, the better the test, the better your confidence. And so you’re, you’re actually able to do changes without any tests you don’t know, like, are you messing up completely here or, you know, are you introducing a lot of side-effects and so on? Is that still in definition that holds true for you today? Or would you say that over time, the definition of, you know, what legacy code is changed for you?

Michael Feathers:[00:24:09] Well, I think any definition like this. And instrumental. I was actually the time I came up with us working with a team and I sort of just got angry and I said, you know, people, weren’t writing tests. I’m kind of like, you know, it’s kind of like, you know, this is legacy code because it’s code without tests. And I started ranting a little bit right in front of mine, says, you know, you should write that down. I’m like, okay. So I did. But the, the reason why I really was trying to press that point is because it was like really obvious to me through my experience at that time that. There’s a real strong, qualitative difference between code that has test coverage and code that doesn’t in the sense that if you don’t have test coverage, quite often, you’re scared of making changes and you can be much more conservative about how you, you know, do things you may not refactor as much. And you know, just, you, you have like a, a greater sense of ease working in code that has decent cusp test coverage. And I thought that qualitative difference is just so high. That’s worth going in highlighting that and basically going and tying that into a definition of legacy code. But then, you know, there’s the thing of kind of like there’s many different definitions of what legacy code is, and, and they’re all useful to some degree and that’s fine, but you know, I think for people that need to hear it, that’s the one I still use just because it’s, you know it helps people go and it’s, it’s a definition which kind of points to the solution, which I think is useful for us. If we’re trying to go and galvanize attention towards better practice.

Michaela:: [00:25:32] So on your head you also wrote. What we call legacy code is exactly what you would expect when developers turn over his I fast error, dent code turnover. Right. So for me to seems very much it, legacy code has to do with the loss of the knowledge about the code base. Right? So if you’re, and this sometimes has to do with the technology as well. Right? So if you think about systems, you know, written in some languages, Well, we just have really only a few people that are still familiar with this code it’s legacy code, right. Or if you’re having a code base and people leave, even it’s written in reacted, she’s now, you know, modern and that everybody knows it. People don’t have knowledge about the code base. So it’s legacy code. Is that something that you think also rings true for you?

Michael Feathers:[00:26:18] You know, I kind of like somebody offered that as like a an alternative definition is that, you know, legacy code is the product of, you know, it’s when your team turns over faster than your code turns over. Right. That kind of thing. And I think it’s important to go and basically see that system dynamic because it really affects. A lot of the decisions we make about process and team structure and all these things going forward within our organizations. I remember, I try to remember which tool this was. So I won’t mention the name because I’ll probably get it wrong, but there was like a tool that’s widespreadly used within the industry of database technology. And my understanding is it’s actually done only by two or three people. And they’ve been working on it for decades and it’s kind of like their life work is basically going to supporting this particular piece of software. Right. And to me, that’s almost like the ultimate fantasy in a way. It’s like, Oh, you know, have this house that you live in, that you basically sort of like remodel, continuously accepted this code. And then basically, you know, it so intimately that you’re. In this space where basically it’s never really legacy to you because you’re constantly able to go and improve it and add to it and stuff along those lines. Right. And it should never be something which is too big, where it’s too big, then, you know, It’s so big that a couple people can’t work on it together, you know, that you need an entire team. But it’s interesting without to go notice that that’s almost like an idealistic situation of having something that’s durational, the people are going to be with it. Long-term, it’s relatively small and you can basically do a lot of really great practice with it. But the thing is, it’s kind of like in. The typical development that happens to these days that never really quite happens. The software tends to grow up, grow bigger than us bigger than what will fit in like two people’s heads, for instance. Right. And beyond that people will basically leave and go to other jobs and other people will come in and stuff like that. And it’s these things that happen, which go in, tend to go in. Cause you know, the, these issues that we tend to have, and then we have to go and introduce practices like, you know, extensive testing. You want to make sure that we can. Detect when something goes wrong in this thing that we don’t quite understand when we make changes to it. Right? All these things are almost like props that we use to go and basically deal with this fundamental mismatch between the lifetime of the team, the lifetime of the code. And I think it’s kind of a fascinating thing to go and recognize that those tensions are inherent in what we do. And it’s not that we’re bad programmers. We’re just dealing with a pretty hard problem that we have this, this lack of alignment between team and, you know, piece of code that we’re working on.

Michaela:: [00:28:44] Yeah, exactly. And I think it has also to do with, I mean, there are so many factors that influence that. So for example, in our industry, people that are, you know, five year in one company, this is like, Five years. How could you say that long? Right. Like people are turning over really quickly also for various reasons. Very often also because they want to level up. And because there is, or yeah, because there is a lot of opportunity out there, right. So people can choose, pick and choose, be quite choosy. But on the other hand, as you said, well, people are leaving and they’re with them. A lot of knowledge is leaving, which I think sometimes organizations still don’t recognize the value of the, just the knowledge that people have in their head that they accumulate. Right. Because, and we see that and you know, that I’m a big fan of code reviews, for example. And I did a lot of research on cultural reason. What we see for example is that. The person who has seen fight at least once this is the big zero to one, right. Has seen the file, the, the code that you’re asking them to review, at least once, then it will give much better feedback than before. Right? So if you look for example, usefulness of feedback, and so how many of the code review comments are useful? We see that if they haven’t seen the file before the code, before the code base, before this part of the code base, before they give around three. Out of 10 useful code comments, right? So only 30% of their comments is really useful to the author. But if they have seen it, at least once it, grows from 30 to 70%. Right. So this is a big jump, but then you only see incrementally, like until five times, then it doesn’t matter anymore. Right. So if a person has seen the code five times, then it’s plateauing the usefulness of the comments that they are giving. Right. So, but culturally is in general. I think it’s a really, it’s a good practice if it’s done right. To help that more people are familiar with the code. So for example, if you have at least two people or three people that have seen the code base, or know a little bit of what’s going on there, they don’t have to be in a, like the author of it. But I think they are quite intimate, familiar with the code base because of the cultural reason we see that. Knowledge really increases that we can measure, even at the knowledge of the code base increases for teams that are doing code reviews versus with teams that are not doing code reviews. How is your experience with that? Is that something that you recommend that you recognize as important and so on?

Michael Feathers:[00:31:08] Yeah, no, I think it is. And it’s, it’s funny with this too, because I kind of come, you know, at least I’m gonna become a consultant. I really got embedded, like in the extreme programming and agile communities. And so we had like pair programming in the very beginning and we would basically use that as like a. A way of going and trying to go and arrive at like continuous code review. And then more recently you have mob programming and ensemble programming as well. And it’s kind of weird about this because it feels wrong in a way to go and have five people working on the same piece of code at once, right. In a group. But I can’t. You know, the more I reasoned about it from first principles, I think it’s actually a pretty decent thing to do, right? If knowledge loss is one of the main things we we deal with over time within an organization and basically making sure that everybody’s involved in the decisions and those, the code intimately, it’s probably a decent investment for an organization to make. It’s a hard sell. I’m sure you know, many organizations, but it’s, it’s also something which is kind of fascinating. I think one things that’s kind of funny with this. I know that like, this is like, Knowing this pod, you’re kind of like asking me a bunch of questions, but with your background in code review, the thing that I kind of noticed, and I’m wondering if there’s any research around this is that sometimes there’s this issue of like, whether people will really be forthright about their criticism of a piece of code. And if they’re not, do we basically just sort of like let quality deteriorate because nobody really wants to step up and say, there might be an issue here, you know, is that a thing which happens in code review that you’re.

Michaela:: [00:32:34] This is definitely something that happens and it happens for various reason, right? It could happen for example, because people know that even if they are criticizing it. The team and the organization, how it’s structured and how, you know, incentives work and all of that. Right. So there’s a lot of that behind the theme thing. It’s too late. Right? So most of the time the criticism that’s not sad is because it’s too late. So even if I would say it right now, we are not going to, you know, change it. We are too far in it. Right. So this is, this is one, one part where this happens quite a bit and it’s really sad. And you know, this is also a planning issue, right? It’s the ticket to big when are we involving people to give feedback? And so, you know, people have worked like a month. On something. And then you’re, it goes higher up and people say, well, this is from an actual perspective. It’s horrible, but it cannot even say it anymore. Right. They cannot change you’re too far in. And then obviously there are also hierarchy issues, right? So is a, is somebody allowed to say something? Is it even hurt when you’re saying something? . People learn if the, Code review feedback is not perceived or not received and not changed people that also learned that this doesn’t, you know, it doesn’t make sense. So this is definitely something that happens. There’s also something called, you know the priming bias. So if you see that other people already looked through the code you’re also primed for their answers. So the best thing would be that people are looking through the code without looking how others responded and say, well, it looks good to me, or, you know,

Michael Feathers:[00:34:05] Yeah. And we’re talking to somebody, an organization, a very big software development organization, and they were saying, we know we hire great engineers. But the one thing that we kind of noticed is that essentially we can see through the metrics that the code quality is deteriorating, but nobody on the team knows because they’re just so used to looking at the same code all the time. They just kind of understand what’s going on with things. So the newcomer. Would be completely, you know, I’m surprised by so one things I kind of wonder about all the time. It’s like, can we basically get new people on the team, people visiting that we’ll be able to basically say, well, you know, you’re saying this is great, but I don’t understand it. And then sometimes I might be like a, like a jolt to go and say, it’s like, wow. You know, it’s like, are we building a silo of understanding here that basically is disconnected from understanding of the world. Might be a possibility with that too, you know, to go and sort of like try to mix things up a bit to the point where the teams don’t become stale in their understanding.

Michaela:: [00:34:57] Then, for example, culture feedback, right? So I’m working also a lot of very often with people or teams on how to give feedback so that others even can, you know, receive it. And very often there is like, Oh, but in our team, we understand when we are talking very harshly with each other or whatnot, right. But this is also a sort of blindness, which I think is very similar to the blindness for your code that you say, well, if you have to be very intimate with your team and know that this is actually not a harsh comment, but it’s a joke for you. Then first of all, it’s not coming to others. It’s not something that you want to leave on because in two years, your team is not a team anymore than it is today. Right? So if somebody looks at this code comment they will not understand. Right. And it’s also, as you said, it’s something that you’re building up where. It’s not conforming to what we were expecting outside. Right. So it’s really something that’s very, it’s a very narrow, very blind view on your system. Right.

Michael Feathers:[00:35:49] Yeah. Yeah, no, it’s, yeah. There’s a lot of really interesting dynamics around all this stuff. I find it really fascinating. It’s funny. Conway’s law, you know, we’re Conway’s laws, you know, saying that the code structure is gonna end up going in, mirroring the structure of the teams to kind of like, you know, look at that at a very deep level and go and say the same thing is true with quality. If the coast starts to be kind of messed up at probably in the case, there’s communication problems within the team, in terms of nobody’s able to go with, stand up and say, there’s something wrong here. Maybe, you know, I mean, it seems like that kind of effect can occur as well.

Michaela:: [00:36:25] Lot of different issues behind why quality deteriorates. Right. So what I also often see you and I mean, It really breaks my heart is that if people want to, but they’re just really, they can’t or they feel that they can’t. Right. And this is very often from an organizational perspective. So one question that I had for you is when you were coming in, I think there’s a lot of buy-in from a path, right? So there’s a lot of top down. Understanding suddenly, Oh, this is important. Whereby teams are dealing with this bottom up, you know approach really have to see, well, I see this is a problem. We feel this is a problem. We don’t have enough time to do it. You know, there’s a lot of deadlines and so on and they would have to communicate up to which I often feel. This is really, really hard. And if you don’t have commitment, this is also what developers say, right. If I don’t have to commitment, I just can’t fix it. It doesn’t matter if I find it important or not.

Michael Feathers:[00:37:19] The advice that might be kind of seen as like problematic in a way. Right. But the thing is, I think sometimes with a good team, If you can find other people on the team that care about co quality issues, the way that you do just form a little bit conspiracy with them. It’s kind of like, you’re not going to ask for permission. You’re just going to make things better silently and just not really talk about it with the rest of the team until they start to notice just like through osmosis, that this is a better way of doing things, right. One of the worst things you can do as a developer is try to lecture your other developers on the team. Right? Nobody likes that. Right. And you know, if you have. Some respect already that you’re able to go in sort of like say, you know, you should really do things this way and it works. You know, communication wise. That’s great. But if you don’t have that, you know, it just doesn’t go all that far. But I think, you know, the, the main thing is the programming can be very fun and cleaning things up can be very fun also. Right. And if, you know, you can develop that kind of culture internally within the team. That’s great. And worked with a team a long time ago that really had this interesting thing. They did great work, but part of it was also a feeling that every other team in the organization was a bunch of idiots. In a way. So it’s kind of like this thing of going and saying, like us versus them and it formed like this cohesive group with them. The thing is they were all smart enough to go and recognize that, you know, that was like not the truth. It was just like this little story they told themselves to basically sort of like say. Yeah. Yeah, we’re doing this great thing. And it’s like, who cares if nobody else really uses it? You know, that way that we intended, it’s like, it’s still okay. I think we can basically play those emotional games a little bit to sort of like not hurt anybody, but also kind of bolster ourselves up as we try to do things. It’s funny, cause I’ve mentioned this a couple of times in interviews and stuff that I really feel that I missed an opportunity with the legacy code book to basically give it a positive frame because even though it can be kind of treacherous to go and deal with legacy code, it can also be like, And adventure, if you basically sort of frame it that way, you know, it can kind of let go and say, look, you know, you’re kind of like going through this crazy jungle and you’re learning things and you’re picking things up and making things better as you go. And that can be a decent way of going and motivating yourself and people around you to go and do some cool things.

Michaela:: [00:39:26] I think that a lot of engineers actually like cleaning up, right. It’s like, If you have like a kitchen sink and it’s, it’s dirty and then you swipe over it and it’s nice. Right? And so I think a lot people also recognize that and it’s, it’s a hard problem, right? It’s on one hand they had problem. There’s a lot of architecture thinking about it. So sometimes maybe people don’t even have the possibility to be involved in such. Higher decisions or impactful decisions. And suddenly with refactoring, all those decisions are actually at your fingertips that you can actually change something and make it better. And, and, you know, it’s in the small, but it can have a lot of ripple effects and all of that. Right. So to think about that, I think can be very challenging and.

Michael Feathers:[00:40:07] Too, when people are talking about what good design is, it’s kind of like, you know, if you give anybody a blank piece of paper and tell them to design something, they can usually do something really cool. But the real skill in design is working with stuff that’s already there, right? Because the number of constraints that you have basically go into sort of like help you exercise your design skill in a way, because you have to go and sort of like work around them and work with them. At least to deeper design insight, working with things where you have, where your environment is a bit more constrained than than you might hope it to be.

Michaela:: [00:40:36] Yeah. So there were a couple of questions on Twitter as well that I want to be even a little bit. So I was thinking about best practices again. So people were thinking about how can we, you know, show best practices. I asked you that at the beginning as well about best practices. And we talked a little bit about transparency and in my recent discussions, I’m discussing a lot with engineers right now. We also talked about transparency and how cool it would actually be. Okay. In an organization or outside of an organization to see, you know, what are people doing and then also seeing the impact, right? So you can pick and choose. And there is also, this is also something that we are lacking a little bit different transparency of best practices. Well, even if practices, right, it doesn’t have to be the best practice, but the practice. How, how is that team doing? How is this team to doing and similar to what you said too, when I’m working with larger organization, we also see that all there’s this division and that division and the third division. And then they think that this division is actually doing the best. Right. And so they’re really proud of their Practices and the other are doing like really bad work. And suddenly you see that people are working and there are constraints. Right? So because one is like the driver division. Yeah. Which is a very different kind of a beach. And if you’re working on the website side of things right. Where you can update things much easier, but it would be really cool to see a little bit. How are people working and H how could you do that in an organization? Is there something that you learned. Where organizations surface that and show what are good practices that other teams should adopt.

Michael Feathers:[00:42:07] Yeah. Typically with organizations that worked with them, I had them kind of like moving too. Like this show and tell mode where like, you know, once every couple of weeks or something like that, people from different groups will present what they’ve done and kind of like just make that available for people to go and see, you know, where the other possibilities are, you know? And it’s, it really does. You know, a lot of it does come down to what you were saying earlier is that some practices might be better in certain types of development than others. But the thing is, you know, you get to raise the consciousness of those things and it’s. Creating forums for those particular things. And the cool thing with that, as you get developers real used to going and doing a little bit more, like say public speaking, even though it’s internally within the company to go and describe, you know, the various things that they happen to be working on and doing. Right. Yeah. I don’t know. I don’t know that there’s anything that’s really like, you know, it’s just doing that. Sorry.

Michaela:: [00:42:54] Yeah, communication, right? Brown bags, for example, that you

Michael Feathers:[00:42:57] Yeah, I think, you know, nothing. I would go and add to that too. Is that even though transparency like that as a good, I think it’s one of those things where it has to be discretionary rather than we’re completely transparent all the time. Right. Within an organization. I think one things that’s kind of cool is that when you have. Different groups of people within an organization working on different things, they can incubate something and basically not worry about somebody going in saying, well, maybe that’s not a good idea. It’s like, no, we’re going to try this for a while. And we’re going to go and see what works with that. Then basically go and give you results. Once we feel more comfortable with that. And then you get like the enhanced. You get enhanced psychological safety within that cloister in a way because you don’t, you know, everybody’s kind of got the buy-in and the relationship with each other. And that’s just a natural part of being human, right. To be able to come and sort of like, you know, grow things in a safe environment and then present them out into the world a little bit. But you know, a lot of this really comes down to leadership really within your organization. Can you basically go and sort of like, make it. You know okay. For things to be, not to be okay. Not be okay sometimes. Right. And just sort of like, make people feel safe to go and communicate back and forth, then, you know, do the things they need to do. So, yeah. Culture again, you know, I think I said.

Michaela:: [00:44:07] That’s true. Yeah. I, this really resonates a lot with me. So maybe the last question that I want to ask you, and it’s a little bit connected to the Twitter. Things is about testing. So I made a study, actually. I think it’s. I dunno how many years ago? A couple of years, eight years, 10 years, 10 years time flies. And I was looking at unit tests versus integration tests and system tests. And at that time, people were all over unit tests, like unit tests, you know, is, is the bullet that brings you joy and happiness. And I, I feel that this shifted a lot over the last year. So right now people are more into integration, testing, more into systems testing. What’s your thought about that? And especially in connection with legacy code, are we still because legacy costs, I think a lot of things were still unit tests, right? So we are connecting, having unit tests and having tests in general around the system to make changes. Has that shifted as well? What do you think about system tests?

Michael Feathers:[00:45:00] Yeah, I think, I think it’s shifted a lot with service orientation, right? When we’re doing like microservices and stuff along those lines, the there’s like a, you know, We talked about like code being alive, right? There’s this great talk from Alan Kay at oops, look basically in the 1990s where he basically goes and draws a parallel between code and biology. And he talks about, you know, his original conception of object orientation being kind of like cells communicating with each other through messages, by chemical messages. And it’s kind of funny because when you send messages from one cell to another via chemicals, it’s asynchronous and it made me kind of realize it’s kind of like, you know, Well, we wanted Ohio to be Israeli. What services are in a way it’s like you can send a synchronous messages notifications across these services and they can be really very well decoupled from each other. Right. So basically going and testing things at a service level is a very decent thing to be able to do. The unit testing thing was really very proud, met pragmatic. When it comes down to, if you’re making a change to a particular piece of code, you want to be able to go and get close to it. And if you can basically go and write tests, like at the class level around it, then you’re in a situation where you can go and get immediate feedback about what you’re happened to be doing. And so it’s like this way of going and sort of like building. You know, building like this assurance as you basically go and make changes that you really are doing the right thing. So unit, it seems like units in object orientation tend to align around classes or aggregates of classes. And so I tend to see those as being a unit in a way and that wrong. And it’s really all about going and making it possible to go and get that feedback and, and build, you know A knowledge-based through tests that basically can go and find out very quickly by running whether things are working or not. One of the things I’ve been kind of throwing around is as a frame recently as that essentially test determined where your unit in a way that if you can basically go and get an area of code. And it’s easy to go and basically test it. Then that’s a decent, decent definition of unit as you can ever get. And for you, a unit might be a service where it might be a class, but it’s the point at which the testing comes to difficult that you basically know that you’ve got a modularity boundary, that isn’t all that great. And it’s just, you know, like a way of going and looking at things in that realm. So yeah, I don’t, I don’t really, I think as long as people go and understand that tests and modularity kind of. Work together in a very interesting way. It doesn’t matter to me whether you call it unit tests or systems tests the test will give you feedback about your modularity and that’s a cool thing to know.

Michaela:: [00:47:26] Yeah. Yeah. Like the, like the frame so well, Michael I think we are at the end of this show, I’m really happy that I could pick your brains for so long. Is there something that you wanted to let my listeners know before we are ending? And I will definitely link a couple of things down there in the show notes, but is there something that you, you know, that you’ll want to end the show with?

Michael Feathers: [00:47:48] Yeah, I guess just basically going in saying that we’re all part of one, we are part of the system as humans working in software development, and we need to basically take the systems that we work on seriously. And, you know, I think that seriousness for us means kind of like looking at them as entities that have their own qualities and we can make them better. You know, the thing about this, that. I think it’s kind of fascinating is that if we are going from job to job and place to place, and these systems remain behind, you know, it’s good for us to go and actually exercise enough care that we leave the place, leave the system better for the next people, because you know, that’s just what empathy is all about.

Michaela:: [00:48:26] So you show your empathy through your code, right? In the quality that you leave for the people that have to deal with it.

Michael Feathers:[00:48:34] like a couple of years ago. It’s like code is the way you treat your coworkers. Right. And it’s kind of like, it’s true. You’re not really us. So

Michaela:: [00:48:41] Yeah. Yeah. I like that end note. Thank you so much. Um, was a very inspiring talk. Thank you so much for taking the time.

Michael Feathers:[00:48:48] Excellent. Thanks.

Michaela:: [00:48:49] Okay. Bye.https://grain.co/highlight/lUGaWr1iPs39D4HeOqszHXnglk9i9tIRzcy6wk52

 

Episode 35: How Programmers Think and Learn

In this episode, I talk to Felienne Hermans, who is an associate professor at the University of Leiden and researches how developers think and learn.

We talk about:

  • why it is so hard to read and understand code,
  • her book “The programmer’s brain”,
  • how we can learn easier to program,
  • techniques to understand complex code quicker,
  • how a shared vocabulary can help teams, not only during code reviews
  • and her process to write a book developers will love.
Continue reading