what the heck is data-oriented programming?

In this episode, I talk to Yehonathan Sharvit, author of the book Data-oriented programming. Yehonathan is a developer, author, and speaker. He has tons of experience in full-stack development using various languages such as Java, Javascript, and Ruby. But his favorite language is Clojure. He bundled all this experience and knowledge into his book which should be finished this summer.

We talk about:

  • the basics of Data-Oriented Programming,
  • how Data-Oriented Programming compares to object-oriented programming and functional programming,
  • and how we can apply it in our codebases

This episode is sponsored by Tonic.ai – where your data is modeled from your production data to help you tell an identical story in your testing environments.


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

Transcript: What the heck is data-oriented programming?

[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.]


Dr. McKayla 00:04 Hello and welcome to the Software Engineering Unlocked podcast. I’m your host, Dr. McKayla and today I have the pleasure to talk to Yehonathan Sharvit. But before I start, let me introduce you to an amazing start-up: tonic.ai – the fake data company. So what does tonic.ai do? I’m sure you know how complex and cumbersome it is to create quality tests! It’s a never-ending chore that eats into valuable engineering resources. Random data doesn’t do it — and production data is not safe (or legal) for developers to use. What if you could mimic your entire production database to create a realistic dataset with zero sensitive data? That sounds amazing, right? Tonic.ai does exactly that. With Tonic, you can generate fake data that looks, acts, and behaves like production because it’s made from production. Yet, tonic.ai guarantees privacy so your Datasets are safe to share with developers, QA, data scientists—heck, even distributed teams around the world. Visit Tonic.ai, to sign-up today or click the link in the show notes to get a free, 2-week Sandbox.

But now back to Yehonathan. Yehonathan is a software developer, author, and speaker. He has tons of experience in full-stack development using various languages such as Java, JavaScript, Ruby, but his favorite language is Clojure. And he bundled and packaged all of his experience and knowledge into his new book Data-Oriented Programming. This is also the reason why I invited him today. And I’m super thrilled that I will dive with him into how to design and build software that deals with information. So Yehonathan, thank you so much for being on my show. Welcome here.

Yehonathan Sharvit 01:19 Hello, McKayla, I’m really glad to be here with you.

Dr. McKayla 01:22 Yeah, I’m also really thrilled. And I heard that you are giving away one of your books, digital copy of your book to one of my listeners. So what do you have to do to win this book? Well, retweet today’s episode and like it, and then you’re in the pot to get one copy of Data-Oriented Programming from Yehonathan. So, but, Yehonathan, what is this book actually about?

Yehonathan Sharvit 01:46 Okay, so this book is about a simple way to reduce complexity of information systems. And by information systems, I mean, a program that manipulates data that doesn’t belong to the program., data that comes from the outside world. For example, a front-end application that receives data from a back end, or a back-end application that fetches data from the database or an API. It could be also a web worker that reads data from RabbitMQ or Kafka needs to process it and passes it forward. So all those systems have in common that they manipulate data. But the data does not belong to it, the data or the information existed before the program, and will continue to exist after the program dies. And those kinds of systems, which is basically what we do on our day-to-day basis as full-stack developers need, I think, a different and a simpler approach to how we represent data inside our programs.

Dr. McKayla 02:50 So I realized that when I looked at the first topic, or the first subtitle, Unlearning Objects, it was very, very clear to me that it somehow has something to do with object-oriented programming, and that you want actually a paradigm shift here. And you think now about data-oriented programming, more or less, right? And so, that this can somehow improve our applications, and probably our maintainability. So what is that shift from object-oriented programming to data-oriented programming? And why should we unlearn objects?

Yehonathan Sharvit 03:24 Okay, that’s a great question. And let me tell you how I see it. I practice meditation. I’ve been practicing meditation for around 10 years now. And to me, there is quite a similarity between what meditation guides us to do and objects. So in meditation, the basic assumption of the basic principle is that the main cause of our suffering doesn’t have to do with the reality itself, but it has to do with the way we perceive reality. So our mind projects, something, an object on the reality. Object causes us suffering. But the reality on itself does not cause any suffering. And meditation guides us to remove the glasses that our mind puts on reality and to look at the reality as it is. And if you are able for a moment to look at the flower as an idea, if you are lucky enough to explain that it’s a joyful experience. And even pain, if something is painful, if you’re able just to feel the feeling of the pain with no interpretation of the mind, with no meaning about what does it mean about me but just experiencing the pain as a physical trigger, then the pain is not as painful as it seems to be. So that’s what’ my take on meditation is. And in a sense, object-oriented programming is causing suffering to the developers because instead of looking at reality, at data, at information as it is, we took our mental model, and then we stepped into infinite complexity system. But that’s not that the data on itself or the information on itself is complex, it’s the tool. The object that we use to grasp data is causing the complexity. So in a nutshell, I would say that most of the complexity that we have in our program is accidental complexity. It’s complexity that we have created because of our mental model. It’s not inherent complexity that has to do with the business domain.

Dr. McKayla 05:25 Can you give a concrete example of how object and object-oriented programming increase the complexity of our system?

Yehonathan Sharvit 05:33 Yes, so let’s take… In the book, I take a simple example of building a library management system. And let’s say in the library, you have books, and you can do many kinds of operations with books and authors. And in object-oriented, what you do is that you create an object that represents an author, and you have methods inside the objects to manipulate the author object. But the fact that you bundle together code and data or behavior and data creates complex hierarchy diagram. Suddenly, many classes need to input the author definition, just in order to access a simple field from the author. Or if you want to create a new author or an author with different fields, you have to create all the method of the author. Or if you want to test how the function of something behaves on an author, you have to create this complex object just to check for little things. Sometimes we say that you want the banana but instead of having the banana, you get the banana and the gorilla and the jungle, while you only want the banana, only one, the name of the author.

Dr. McKayla 06:36 And so how would I design that system? Let’s say with this library, and the books, how would I design that in data-oriented programming? How would that look differently?

Yehonathan Sharvit 06:46 So it will be very simple. First of all, you separate data from code. And now you ask yourself, how should I represent data. So you have stateless objects or modules for the behavior. And you have data with no methods, data objects, or data classes, or data maps for the data. And what is data? Most of it is just record. So its maps are HashMaps, with fields and values. And that’s it. So you represent your whole domain as a nested combination of maps and arrays, and integers and strings and kind of JSON, what JSON has brought to the world since it has been adopted, and not only JavaScript, it’s simple tools to represent data. What do we have in JSON? You have strings, you have integers, numbers, Boolean, node, to represent information that belongs to the real world.

Dr. McKayla 07:37 Okay, and so how would I structure the code in terms of files, for example? Where do I put all that data information? And the functional information will have separate files, two files, three files, 10 files? How does it work? One file?

Yehonathan Sharvit 07:52 Yeah, yeah, the thing that I didn’t mention is that in data-oriented programming, we separate between the data representation and data validation. So let me give you an example. When you create a book with the title, and the publication year, and the list of authors, you just create a map, you don’t create a book object. So you don’t need any class to instantiate a new book, it’s just a HashMap. If you’re in a language like JavaScript, Ruby, or Python, you have dataliterate for that, if you are in a language like Java, or C # or statically typed language, you have a HashMap constructor. So that’s it, you don’t need any type definition for the book. And you organize your functions, you would in a regular object-oriented program, but the functions are much simpler, because they are stateless, they always receive as an explicit argument the data that they manipulate, so there is no implicit leads or set or reference to the object because there is no object.

Dr. McKayla 08:47 Okay, and so you were already talking a little bit about verification. And so for me, the first question that now comes to my mind is that actually with the typing, right, and that I can even create custom types, and then, you know, enforce them in the system. This gives me somehow also security that a book actually is how I imagined a book to be, how do we have that in data-oriented programming? How do we verify that it looks like this? And you know, like, because JSON again, right, we have we have some simple types. But you know, you could present me any data. And I’m not sure if this is…

Yehonathan Sharvit 09:22 Yes, exactly. So you could, for example, receive a map that you think is a is a book and a book, you’re expected to have a field name title. And suddenly you get a map. And the field is named D title, for example. So how are you going to deal with that? And that’s a great question. And the thing is that you deal with that, like when you encounter surprises in the real world. So surprises happen in the real world. If you, over the wire, let’s say you access an API and you ask for a book. And for some reason, there is a bug in the API, the server that serves the API, and you receive a book with a room field. You need to deal with that. And the types won’t be helpful there. The types will just fail, try to pass the JSON into a book with a field title, and there is no field title. And you will have either an exception or a nice error message. So this is applicable exactly the same way. In data-oriented programming, you define your schema. In a schema language like JSON schema, you receive your data presented as a hash map. And there are libraries in all languages alone to validate a piece of data against a schema, you validate, if it’s valid, to move forward, if it’s invalid, you deal with that by sending an error message to the user, by whatever, how you deal with that. But the important thing is that you embrace surprises, you don’t assume that everything is going to work as expected. Like in real life, you know, you learn at university, you read books, you consult professionals, if then you expect that life will behave exactly as you have been told, you’re going to be quite upset. So the approach is that you embrace changes and surprises. So you have modeled, you have expectations, but you have little maps or glasses, but you don’t confuse… There is a great quote that I remembered today or yesterday about the map is not the territory. So objects are like map, schemas are like map. Quite often in object-oriented programming, we tend to think that the map is the territory. There are no objects in the real world, the information about the book is not an object. It’s a piece of information, you might decide to represent it as an object in your program. So that’s your map. But that’s not the territory. While in when you represent your program information about the book, string map, just a map with keys and values, this is much, much closer to what it looks like for real, there is less of an impedance mismatch between how the information exists in the world and how you present in your program. So it’s a move of humility in the sense.

Dr. McKayla 09:38 And so I think I get a good understanding of how it’s different from object-oriented programming. But what’s the difference to functional programming now? So where do they overlap? Or where do they differ, those two different ways?

Yehonathan Sharvit 12:10 Yeah, that’s a great question. So first of all, they overlap, functional programming and data-oriented programming, by both approach in that we need to separate between code and data. So that’s exactly the same. But when it comes to how should we represent data, in most functional programming languages, like Haskell, OCaml, etc, you’d use custom types to represent data. While in data-oriented programming, you don’t use custom types, you use generic data structures. So that’s the main difference. And there is another area where they overlap, the data is immutable, in both in functional programming, and in that alternate programming, we never ever mutate, we always create a new version of data to manage changes.

Dr. McKayla 12:54 Okay, so one of the big benefits from data-oriented programming that you see is that we don’t have the custom types. I’m a big custom-type person, right? I’m always happy if I can create the type. And I have, you know, some enforcement around that, you know, you already described it to me, but still, what are some of the really cool things? Or why does it help me not to have the custom type and not such a strong typing system around what I’m doing?

Yehonathan Sharvit 13:23 I’m going to send you back the question, what is it that you liked so much about type?

Dr. McKayla 13:27 Well, so we were thinking about complexity, and I think I’ve never, not at least intentionally wrote a data-oriented program, right? So I can just go from my experience that I have so far. And I would say that strong typing helps me to avoid a lot of complexity around ensuring that, you know, the thing that I’m getting is actually what I’m getting, because it’s already, you know, somehow, even before it runs, right, so it’s definitely, I can statically assure that this works. Now, if I remove that layer, I feel like very insecure, I feel like oh my god, now I have to write all this logic that you describe of like, I’m dealing with this uncertain world. And I have to check this and that. And I totally understand that this is somehow reality. But on the other hand, why do I have to create my reality more complex, in my mind, right? More challenging than it has to be? Because if I have the type system behind it, I can say, well, I know that this is a book and this is how it looks like, and otherwise I will not receive it here.

Yehonathan Sharvit 14:27 Perfect. Great question. Before I answer, let me ask you another question. Do you also enjoy the kind of help that you ID gives you when you have type, autocomplete… that you can never miss type a field?

Dr. McKayla 14:40 Yes, I actually like that. Yeah. And I like that. I have a tooltip that I know Oh, these are the fields that I need. You know, like, I love all of that very much.

Yehonathan Sharvit 14:49 Okay, perfect. What you said totally resonate to me. Now, are there anything that you dislike this type, or for you it’s the best that could be in the world?

Dr. McKayla 14:59 There are probably tons of things that I disliked. But now that I have to think about it, but you probably can tell me…

Yehonathan Sharvit 15:06 Okay, let me challenge you, when you have, let’s say a book record. That is, how easy it is to serialize it to JSON?

Dr. McKayla 15:13 It depends. If I need a higher library, sometimes it’s easy. Sometimes it’s hard.

Yehonathan Sharvit 15:18 For my experience, it’s always had with static typing. There is no native way to take record a custom type and to serialize it to JSON. You need always to hack something to use reflection, or some kind of hack. You agree.

Dr. McKayla 15:35 It’s not straightforward. It could be, it could be more straightforward. Yes, I agree.

Yehonathan Sharvit 15:39 if if you program let’s say you write a game, for playing with the library, then you create the books and the books stay in the program. So you never need to externalize data, that’s fine. I have nothing to say against types, because it’s a closed system. But if the moment you need to externalize your information to other, you need to go out of your types anyway.

Dr. McKayla 16:04 I never saw that as a real problem. Because it’s just another step of things that we have to do, right.

Yehonathan Sharvit 16:11 I’m curious, how do you serialize? Let’s say you have a nested record that describes the whole library with books and authors. How do you make from it? No, I’m ot saying that… Yeah, it definitely takes time, right? It takes time and effort. And you have to write it, right? I probably write the record, but I’m not sure if this is. Or I asked the other person… Yeah, you write to custom logic for any piece? Okay. So one challenge, another challenge. Let’s say you have in the book, you have a field called title and field, publication year and a field author. And let’s say you want to rename one of the fields, you want to call it, author, because that’s how you need to send it over the wire for some reason, what are you going to do? Create a new type, exactly like the first type. So it’s going to be called Book Two, which is exactly a book, but just the field also is called the book author. Usually there is a profusion, a profusion of types. And yeah, each little module that needs to have a different look at the same data or very similar data will create its own type. That’s the kind of complexity I’m referring to. There are types that are intertwined with different things, different glasses to look at the same reality. Another example, let’s say you have two modules that have the same type with the exact same field, but one type belongs to one module, and one type belongs to another module. Now you have one by module, a one by module b with the exact same field. If you compare them, the language will tell you it’s not the same, two different type instance. But the fields are the same. So it’s two glasses, that look like the exact same reality. So instead of comparing reality, you compare your glasses.

Dr. McKayla 17:53 Yeah, I think I probably would need a very concrete example to see the different instances of how or when I encountered those problems. But I see where you are heading towards. So what are the programs that you wrote, or the products that they created, where all of those challenges that you describe have been so predominant, that data oriented-programming really made sense? And how did you switch from, you know, like, probably had like already a codebase? So how do we go from that codebase that we have to a data-oriented code base? What steps do we need here?

Yehonathan Sharvit 18:20 Yeah, if you take a look at the book, you will see that basically, data-oriented programming is made of four core principles. You don’t have to apply all of them, you can apply principle number one of data-oriented programming, and change your code base according only to this principle. So for example, you will take a class that combines code and data and split it into two classes: one for the code, one for the data, and it will be already… It will have beneficial impact, if will lower the complexity of your class diagram. After that, you can say okay, this piece of data, maybe I can represent it as a HashMap. Instead of creating my custom type, and see if it makes sense, maybe something that you need to send over the wire as JSON, instead of creating a custom type and then a custom JSON serializer take a look and say, Okay, this, it will make sense to leave it as a HashMap. And then you get the serialization JSON for free. Then the third principle, you can play with schema languages like JSON schema, and see how it looks like to define the schema of your API, defining the rules inside your classes. And then for example, you have a REST endpoint that expects a payload with a specific shape. You define the payload of the request… JSON schema, and you validate that the requests that you receive correspond to the schema. And finally, the last principle, you can avoid mutation and instead of mutating in place you try to create when it makes sense a new version of data and see if it helps in terms of state management.

Dr. McKayla 20:03 But it also means that it plays nicely together we can have an object-oriented or functional programming environment or system and then add…

Yehonathan Sharvit 20:12 Yes.

Dr. McKayla 20:13 Parts that are benefiting from the data-oriented paradigm and transfer that into that?

Yehonathan Sharvit 20:20 You could have an object-oriented programming style or language, embracing the data-oriented programming paradigm.

Dr. McKayla 20:28 Okay, but it can still live together, right? So I can have like a large part of my codebase has objects and works in an object-oriented way. And as you said, Maybe I’m taking just parts of some of those objects and separate data from logic and so on. But the rest will still be very OO, right? Object-oriented.

Yehonathan Sharvit 20:48 Yes. And that will be the advice I would give to someone, not to adopt the will directly but to try when it makes sense. And if you… it’s a place where you’re really scared, let’s say if you don’t have your types, it’s fine. Don’t start from this place.

Dr. McKayla 21:01 Okay. Another question that I had for you is that I wanted to say data-intensive application. And in our pre-recording session, you said no, no, don’t say data-intensive application, say, information systems. Why? What’s the difference for you here? I think I grasp it now a little bit. But I think probably it has to do that it doesn’t have to be data-intensive. You can just have normal data usage. But why do you prefer information systems and not data-intensive applications?

Yehonathan Sharvit 21:32 Yeah, that’s a great question. When I hear the word information, it’s clear to me that it’s something that exists outside my program. information could be in a database information could be in a program, it could be in a file, it could be in the real world. And when you say data-intensive application, to me, it sounds like something at scale with lots of data, lots of traffic, that has nothing to say about how to manage data at scale, it has to say how to represent data in a simple way.

Dr. McKayla 22:03 Okay. Yeah. I mean, a lot of systems have databases at least, right? Like they are probably applications that don’t have a lot of information. They don’t need a database, but I don’t know many…

Yehonathan Sharvit 22:15 I mean, they need a database. But what I mean, is that the scale doesn’t have to be… the throughput doesn’t have to be big.

Dr. McKayla 22:22 I understand. Yeah. So actually, every application that has or deals with data and information that stores it, somehow retrieves it somehow, transforms it, it would be interested to look at data-oriented programming, in your mind, or are there some specific kinds of applications that you would say benefit more?

Yehonathan Sharvit 22:40 Any application that is in the stack of what we call full-stack development, front-end, back-end worker will be… it will benefit. I think where it doesn’t make any difference with…. it won’t benefit. If you want to write a compiler, or to write a game engine, or something that lives in a closed ecosystem, where you have no surprises. If your data never surprises you. And you don’t need to send it to other, you don’t need data-oriented programming.

Dr. McKayla 23:09 Yeah, I like that. That’s very clear.

Yehonathan Sharvit 23:11 If you communicate with data to different systems that use different programming languages, then it makes sense.

Dr. McKayla 23:18 Okay, so the last question I have for you is about the style of the book, actually. So your book is actually written a little bit differently. It’s a story, right? It’s a story and the whole information, the learning experience is actually guided through personas, characters that are doing something, why did you choose to write the book that way? Which is very different from other technical books?

Yehonathan Sharvit 23:43 Yeah. So there are several reasons. One of them is that I like story. And I need to admit, it’s difficult for me to read technical books. It’s very difficult, I get bored, or I fall asleep. And when I read the story, I’m entertained, I’m energized. So I wanted to invent a story. But it’s tricky to make a story in the context of technical material, but I wanted to. I had this idea in the back of my mind. And then when I wrote the first chapter, as a regular chapter, I struggled with finding the proper tone. I was either too enthusiastic and too selling or too boring. I didn’t know how to deal with the objections that I know the readers will have. So I played a little game between me and myself, part of me that played the data with the programming mentor, and other parts of myself that would play the developer. I made little discussions between them. So the mentor would say, types are problematic. And the developer say, but, why? I like types. It brings me safety. Uh huh. And then he challenges m,e then I need him to answer his question.

Dr. McKayla 24:54 Oh, that’s what you did with me today.

Yehonathan Sharvit 24:56 Yes, yes, exactly. I was already prepared. And sometimes, I felt like kind of schizophrenic. Like I have two personalities. But for me, it was the best way I found to deal with questions. And many readers told me that quite often when they read the book, in their mind, they see the character as the question just the moment the question arises in the mind. So that’s how I decided to make dialogues between the character and others. Okay, now I have the dialogue with, they’re going to talk forever with no context? So sometimes I put them in the coffee shop, and sometimes in the university and sometime in the office at some time in the park, and sometimes in the countryside. And then I made a little story around the character and their journey toward enlightenment.

Dr. McKayla 25:45Yeah. And so Manning, right, this is a Manning book, right? Manning has this pre-access, early access thing. Yeah. And you have people that actually read already your book, and you’re getting feedback. Do they like this kind of new style? Are they surprised?

Yehonathan Sharvit 26:01 I think they’re surprised and they like it, and they comment on it. And they provide very useful feedback on it allows me to improve the book, while I’m writing, I also have a reader from… As you may have guessed, I’m not a native American speaker. I was born in France. And I have a friend in Boston, I think, that liked the book and offered me to review the whole book, and reformulate it in proper English.

Dr. McKayla 26:26 Oh, nice. That’s very good.

Yehonathan Sharvit 26:27 We had two weeks of fun together, we sent him the chapters, and it will send me reviews and comments. And it move dbeyond only correcting the English. He suggested little changes to the story, to the setup, to the characters. That was one of my best experience, my best interaction with readers, that they actually participated in the book, they contributed in the book. Is that open source, it’s like an open-source book, in a sense. A collaborative book.

Dr. McKayla 26:54 Very nice, yeah. And so this actually brings me to the end of our episode, and I want to remind our listeners that they can win a book, you are giving away one copy. They have to retweet and like this episode to have this chance. And then in a week, 10 days later, I will, you know, raffle and pick one lucky person that can read the whole story and find out where the characters are around and how they’re discussing the pros and cons of data-oriented programming. So Yehonathan, thank you so much for being at my show. It was really a pleasure to talk to you. And yeah, thank you so much.

Yehonathan Sharvit 27:32 Thank you, McKayla.

Dr. McKayla 27:33 This was another episode of the Software Engineering Unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast, send the episode to a friend via email, Twitter, LinkedIn, well, whatever messaging system you use. Or give it a positive review on your favorite podcasting platforms such as Spotify or iTunes. This would mean really a lot to me. So thank you for listening. Don’t forget to subscribe and I will talk to you in two weeks. Bye.

Improving Code Reviews with Github’s Copilot

How does GitHub Copilot and Codespaces help data scientists to write, understand, and review code?

How to write tests that find bugs

Dr. Mauricio Aniche explains how developers can write tests that find bugs. Writing effective test cases that bring confidence is not that easy. Many developers are familiar with testing frameworks and regularly write automated software tests. Yet, often they don’t test systematically. That’s why Mauricio writes a book called “Effective Software Testing” which shows practical approaches to systematically test software. You can win a digital copy of the Effective Software Testing book, when you like and retweet this episode’s link, which you can find here.

We talk about:

  • the difference between effective and not effective test cases,
  • how domain-based testing helps to write good test cases, 
  • how you can use coverage reports to find missing test scenarios,
  • how to write testable code 
  • and about the importance of maintainable test code.
Mauricio Aniche

Today’s episode is sponsored by Codiga, a smart coding assistant and automated code review platform. Try Codiga for FREE!

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

Transcript: Effective software testing 

[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.]

[00:00:00] Michaela: Hello, and welcome to the software engineering unlocked podcast. I’m your host, Dr. McKayla, and today I have to pleasure to welcome Dr. Mauricio’s Aniche to talk about systematic software testing. 

But before I start, let me tell you about an amazing startup that is sponsoring today’s episode: Codiga. Codiga is a code analysis platform that automates the boring part of code reviews and lets you merge with confidence on GitHub, GitLab and Bitbucket. I’ve worked with Codiga for around one year now, and I love how it also guides me in discovering and improving, well, the “not so nice parts” of my codebases. But there is more, Codiga also has a coding assistant that helps you write better code faster. Find and share safe and reusable blocks of code within your favorite IDE on-demand while you are coding. Learn more at codiga.io – that is Codiga.io.

But now, back to Mauricio.

Mauricio is currently setting up the internal tech academy of Adyen to better onboard developers and help them grow and upscale their skills.

In addition, Mauricio is also an assistant professor at the Delft University of technology. The reason why I invited Mauricio here with me today is that Mauricio writes a super exciting and very practical book about software testing. And he agreed even to give away one digital copy of his upcoming Manning book to one of our listeners.

So you asked, what do you have to do for that? Right. Well, there’s the chance to win this book. If you like and retweet this episode’s, tweet, I will put it in the show notes, or you can find it on se_underscore unlocked on Twitter. For an extra chance to win the book, you can add a comment on your personal best testing practice. But now let’s welcome Mauricio. Mauricio, welcome to the show.

[00:01:13] Mauricio: Hi McKayla. Thank you so much for the invitation. It’s a pleasure to be here.

[00:01:17] Michaela: Yeah, I’m super, super excited. I’m so excited to learn about this book. I have a copy already here with me, right? So I’m following you actually, while you’re writing it and you’re really far already.

And so I have a lot of questions and I think we can, you know, look at systematic defective testing throughout this episode and we can really deep dive and yeah, I can learn a lot and my listeners can learn a lot. So maybe the first question that I have is what. Writing tests in a systematic way actually mean to you?

What is that? What is systematic software tests?

[00:01:54] Mauricio: That’s a super good question. Mckayla, anything. That’s what makes my book different from the others? [00:02:00] So I think we are now super good at writing tests and we’re super familiar with tools like J unit and et cetera. But when it comes to write a test cases themselves, a lot of times we just follow our gut feeling.

No, our experience of course is super nice when, you know, learn a lot about what crushes a lot. So we write tests for this, but this is not really systematic. So what my book tries to do is to discuss techniques where you can try to create those test cases in a systematic way, kind of if you follow this recipe, Maybe the recipe will help you to come up with the interesting test cases that you need.

So this is more or less the whole story of the.

[00:02:45] Michaela: So when you say systematic and you know that we have to learn it, I’m thinking back at university. And the first thing that pops into my mind is fussy testing and, you know, and maybe verification and all of that, which you know, is scary. And a lot of developers don’t do it and maybe.

That practical. It’s not that scalable. Are we talking about those kinds of things or are we more thinking about edge cases, for example, and you know, what, what is exactly the systematic way to write test cases? Is it, is it.

[00:03:18] Mauricio: It is not, I think it’s closer to the thinking of edge cases, as you mentioned, so really close to the way developers write tests nowadays.

So it’s not a big jump from what you’re doing now to what I’m trying to propose in the book. And so think of, you know, you have this method to test this method receives two or three parameters. My book basically says, you know, look to the first person. What is it? Is it an integrator? Is it a string? If it’s an integrator, maybe you have these cases to think about, then go to the second pyramid there, go to the third parameter, then try to see how those three parameters interact together.

So it’s again, super similar to the unit test you. Right. But now in a more systematic.

[00:03:57] Michaela: So, is it a little bit like a checklist for me that sounds [00:04:00] like a checklist or, you know even it’s code reviews, you know, we know that the most effective code reviewers are actually the ones that have a checklist, right.

Even if they are experienced developers, because it helps your brain to go systematically through the code and think about, oh, did I think about this, about that? And normally people don’t even read the code review checklist anymore. They just look at it and you know, oh, I forgot actually about. That part over here.

Can I, can I think about it that

[00:04:27] Mauricio: way? Yeah, definitely. And to be honest, at some moment when I was writing the book, I considered a lot creating a checklist where people could, you know, just try to follow and these ideas are not fully mine. Right. So I learned a lot from what is in there. And so the domain testing techniques that are there maybe super popular in academia, a bit less popular in industry they are doing these checklists without calling them checklists.

Right? Yeah.

[00:04:52] Michaela: In the book you described quite a few different types of testing, right. Domain testing, which I would really briefly describe as breaking down the requirements. Right? So what the program should do and looking at that, then you talk about structural testing, which is looking at the code coverage.

Then you talk about example based testing property-based testing and you talk about contracts. Can you explain each one of those a little bit more in detail and maybe different. What is the most important one? Is there, do we have to know all kinds of this kind of different testing types? Or is it enough if I, you know, do domain testing, are they exclusive or how does the, you know, how do they integrate with

[00:05:35] Mauricio: each other?

Yeah, good question. I think, you know, if you’re a busy person and you cannot read all the chapters, if you read the domain testing one, and then the structural testing one, you can of. The main ideas there. And my suggestion is usually you implemented some feature, right? I’m not really focusing on test-driven development here.

So just imagine you wrote your feature, maybe you did test-driven development, maybe not. And now it’s time that, [00:06:00] you know, for systematic testing, you want to explore all the possible edge cases to look for bugs. My first suggestion is for you to do domain testing, meaning you look at the required. You know what the program needs to do, and this is the requirements.

It doesn’t have to be UML or a user story, whatever you like. And then you systematically apply domain testing techniques there to come up with test cases. So, you know, those are the inputs of my program. These are the outputs of my program. That’s explore. After you do this, you create lots of test cases.

Are you done almost the next step is let’s now look at the source code and try to get some hints from the source code, because you know, sometimes there are small differences between what you envision the program to do and how you implement it. Right. Maybe, I don’t know, you’re doing some crazy optimization there that require some extra testing.

Whatever. And then you look at the source code, maybe use some code coverage tool to help you on doing this. And you then augment the test suites you created with the main testing. And this is kind of the main loop that I see when it comes to create test cases. Then of course, after that, my book dives into different techniques you can do to, to make her tests better.

Like property-based testing, design the contracts so on and so forth. The two techniques are the ones that I consider core for someone that wants to grade group tests.

[00:07:22] Michaela: So domain testing, I have to see a little bit. Yeah. It’s not, it’s not black box box testing because I know the code. But it’s a little bit more about the use cases, right?

So maybe I’m looking at the JIRA ticket or, you know, some, some story in, in, on get hub or something, then I’m reading down what this, you know, what this code change actually should do. And then I’m developing my test for that. And then I should compliment that. With structural testing, we’re actually go at the code and see, you know, how it, how is it actually implemented and dry?

Because code coverage for me would be not only about [00:08:00] how is that implemented, but also like line coverage. Do I, you know, do I hit every line, even, you know, the exception and you know, if they are like, if there’s a switch statement, do I go through each of the cases and so on? Right. Is that, and then I go back to domain testing again, what should this actually.

And blew through that.

[00:08:18] Mauricio: That’s a super good point. And I think this is one of the things my book does differently from the others. And I’m super curious to see how the community views. So when we talk about the main testing, we usually have this black box perspective where we don’t care so much about the implementation.

What I’m trying to say in my book is that maybe you can use those same techniques, but now looking at small units that you kind of know how they work. You know, you don’t have to test the whole program using the main testing. Why not? The same things for small methods where a class, and of course you can then start going up in the test level.

So maybe you test the unit using these and then you’re satisfied. Then you go a little bit bigger and you test the whole component using the main testing. Why not? So I discuss the different test levels as well in the book, but so I want to first thing convince people that the main testing can be done at any levels.

Those techniques applied there as well. That is the first thing. And then the second thing is about code coverage because there were then usually focused on unit testing. And I also want to say that maybe it can help you in other levels as well. And, but I think the main difference from, from what I seen there is that code coverage for me is not there for us to see a number.

And, you know, did we reach our magical number code coverage for, for the CIA to pass? No, it’s more like it’s a tool to augment the tests you created using domain test. So they don’t care about the number anymore. You care about looking at a line that is not covered in reflecting about it. If in the end you achieve a hundred percent, I don’t care.

I just cared that you reflected about things you didn’t test. Okay.

[00:09:52] Michaela: And so, yeah, I know what you mean, but so one of the biggest criticisms for code coverage is [00:10:00] that we are, we are counting or most of the programs actually look. Has this code been executed or not, but we are not looking for.

Assertions for example, or like preconditions post conditions. So for me, they always go hand in hand somehow. Right. So when I think about testing and especially if I hear code coverage and coverage reports and this number right at the question is always okay, well, did I hit every line, but did I even check, you know, what’s happening here or that just execute the program, right?

Because well, if, if you know, a smoke test could also execute a lot of the code base. Actually just, you know, make sure that the code run somehow without verifying that, you know, the inputs and outputs are matching and so on. What’s your take on that. And what is your advice? Is it something that you, you know, that you talk about in your book and the developers should be worried about?

[00:10:54] Mauricio: No, I think that’s, that’s common sense in industry. A lot of developers really hate code coverage. And in fact, I have an entire section on the book called something like, why do developers hate coverage? Something like that. And to me, I think if you’re looking at code coverage as a number only, and then you decide whether you should go up or down, that’s, that’s not useful, right?

Because the number hides a lot of information. So for me, the first way you should use code cover. So again, augment the test cases you created before. So their test should always come from requirements because you should test what the program should do, of course, and then code coverage as a way to document your test cases.

And if you’re using this tool to see if you missed the test case, then code coverage becomes always relevant, right? Because you’re not only looking at, did I cover this or not, but it’s more like I didn’t cover this line. Why is that? Why did I miss this test when I was looking at the requirements? Right.

So it’s more of a reflection. Okay. In my opinion. This doesn’t mean though that the number is completely useless. I liked the code coverage. Number two gives you an overall impression of [00:12:00] how tested your system is because achieving 100% coverage doesn’t mean much because you still can have better. But having like 10% code coverage means something.

It means you’re not really testing anything there. So if you’re there to prioritize where to start, you’re testing the process right now say you’re in a legacy without tests. The code coverage can be a nice guidance for you. So that is the tip. Don’t use code coverages, a number that you blindly try to achieve.

That’s not going to work for you.

[00:12:30] Michaela: Yeah, I liked it very much and it reminds me of. You know, a study that I did during my PhD. And, and the tool that I developed it was actually called test hound. And did you static and dynamic analysis, right? To go through the code and to help develop. I understand the test cases, right?

So again, it was a comprehension tool which I think you’re, you’re using, you know, code coverage and those tools that are out there a little bit to help people comprehend. What’s actually happening in my test suite. How much of my code is actually covered. And then you go in right into for me what I did at that point.

It wasn’t looking at unit, but I was more looking at integrating. And I want to talk about integration testing with you anyway. And so what, what this tool did is it was showing how, how good integrations were covered or which ones were not covered. Right? So again, so a little bit showing the blind spots.

And for that, I was really comparing. Dynamic execution, you know, and, and stabbing execution, because then you could overlay that and say, well, actually, in the dynamic setting through testing, we didn’t cover that part. Right. So yeah, I like that very much. How do you, how do you think about integration tests and system tests and, and unit tests and, you know, there’s this th the testing pyramid, which I think is very, very common and very well known, but is it still valid nowadays the pyramid has like biggest part is the base, right? And then the higher we go up the [00:14:00] perimeter a little bit, you know, reduces its size until, it’s just a little, a little spot at the beginning. So and then each of the levels for testing is actually reflected in this pyramid.

So it more or less says that we should do focus on unit testing the most, then a little bit less on integration testing a little bit less than system testing, testing and so on. Is that something that you recommend is that a, is that the view that you see.

[00:14:26] Mauricio: You are only asking me the tricky questions Mikayla, before I answered the test pyramid, let me make a remark about twos, because you mentioned you developed the tool and et cetera.

And I feel it is about time for us to take the next step when it comes to code coverage tools. Because right now I feel most of them are super interested in reporting a code coverage. But they are less interested in using coverage to help guide developers. What is the next test I should write? And if few, the first company person that does this will have the code coverage tool that will be used in uh,

And then , , you mentioned about the testing pyramid indeed. So the base of the pyramid is the unit testing and the base of the pyramid is a bit larger because you should do more of these, right? That’s the idea of the testing pyramids and you see out there, some people love the testing pyramid.

Some people. Not to focus on unit tests, but focus more on integration and system tests. I belong to the team unit testing. So in my book, I do recommend people to try to focus on unit testing as much as possible, the reason being I believe that if you design your code, well, the core of your system, the important parts of your system will be just a.

For loops and F’s and data structures being manipulated. And those can be easily tested with unit testing and by easily, I mean, it’s super easy and fast to write a test, they run super fast. You can quickly explore different corner cases. You know, it’s super easy to just instantiate a class, put some values in column methods.

That is why I prefer unit [00:16:00] testing. But that requires though that you develop your system with this, you know, unit testing, the stability in mind, and this is not always. Why do some people prefer integration testing and they have a point there because, you know, in lots of types of systems, we do a lot of the bugs only happen when you put components together.

Right? So think of a distributed architecture, maybe microservices, whatever those components are, exchanging messages. And then maybe, you know, a crash will only happen with certain combination of things. And if you’re really mocking out components, you know, when testing one component, you kind of mock the rest, maybe you’re going to meet.

The cool stuff. Right? So that’s why some people like integration testing. And to be honest, I think we should do all of them. My suggestion is focus a lot on unit testing, ensure that your small units, small components are super well tested via unit tests, and then go for integration testing, maybe even system testing to explore things you cannot explore with unit.

Those are more expensive. So maybe you have to prioritize a little bit more, which test cases you’re going to write with all the levels are important. Then the challenge is to find when to write which type of tests.

[00:17:17] Michaela: And is your book going into that a little bit? Is it giving some guidance for developers on when to ride?

Which tests do we get some external?

[00:17:25] Mauricio: Yeah, it does. Right in chapter one already have a huge discussion on the testing. And then I say, you know, based on my experience, when I go for unit testing, when I go for integration testing, and then in chapter nine. So one before the last chapter of my book is all dedicated to integration and system testing.

So yeah, that’s good. There is a bit tricky, right? Because when it comes to integration, testing, and system testing, To me, highly contextual. So if we’re developing a microservices type of application, you may have some best practices there. If we’re developing a mobile [00:18:00] application, maybe you have another set of practices.

So I tried to make a more generic discussion, you know, on integration testing.

[00:18:07] Michaela: So you will also talking about something that I want to explore a little bit at that testability. Right. So you were saying, well, it’s a little bit harder to make things testable and, and, you know, you have to have testability in, in mind.

What does testability even mean and what did design principles, software design principles help us make software system more testable on different levels? Right. So is there a difference in making unit tests more testable versus integration and system tests or,

[00:18:37] Mauricio: yeah, a good question. I think. The testability rules, if I can call them like that are not so complicated, but it’s super hard to apply them.

Once you start to develop more complex software, because your mind is just full of other things to think about. But a testable system is just a system that is super easy for you to control. So I want to test this specific class or a specific component of my system is super easy for me to tell the component what I wanted to do.

And it’s also easy to observe. What this component is doing. So laughter the component is done. It’s easy for me to assert that the component behaves as I expected. So those are the two things that you should always have in mind to design testable systems. Now when it comes to source code and implementation if we think of Java code, for example I think rule number one, when it comes to testability of Java code is your classes depend on other classes.

You should be able to test your class without really depending, too much on the dependency. So we want to be able to mock some dependencies maybe so that you, you gain some control. And so I feel like the most common anti-pattern I see there when it comes to testability is, you know, you’re creating a class.

Make this class to depend on five other classes, but you don’t give away for the testing codes to control these things. And this starts to accumulate, and this becomes like a snowball and [00:20:00] it’s super easy to lose control and then to never be able to write unit tests anymore. So that is rule number one.

There are many others. I discussing a book, so I’m a big fan of the ports and adapter. Execunet all architecture. I feel like they all go in line with the way I see design for testability. So it’s not super complicated, but I feel we need to put a lot of efforts in making sure we are never forgetting to do these things.

Does that make sense to you? Yeah, it makes

[00:20:30] Michaela: sense. The question is a little bit, okay. We can create mocks. We can stop things. But first of all, it, it, it takes a lot of effort right. To do it. And, and then if we do it, like, for example, I am writing a lot of data intensive applications. Right? Very, you have like a lot of, a lot of large data, you know, inputs that are done somehow processed.

And if you want to mock that, or, you know, Parts of it. It really gets very tedious and it gets hard to control. And especially if you’re, you know, like, let’s say we are mining data from GitHub, right. One of the things that I love to do so we are, we are, we are connecting to the GitHub API. And now we want to make our test cases, obviously independent of that, because we don’t actually want to query, you know, those large data sets for every test that we’re running.

So we have some version of that locally. And it gets really complicated. Like not complicated in, it’s hard to do way, but it’s very tedious to do it. It’s error prone. And then, you know, the ABI changes or the format of how they present, you know, the XML structure and so on changes. And then you have to go to your test code into your marks and your stops and your, you know, dummy data.

And, and change all of that. What can we do to, you know, make our lives a little bit easier here? Is there something, or is it we have to deal with it?

[00:21:56] Mauricio: Yeah. Good question. So I feel like if it’s becoming [00:22:00] boring for you to mock stuff, this is just the code telling you that there’s something wrong, right?

It shouldn’t be hard to. So usually my decision-making processes, if things are hard to mock, are there, is there any other way for me to redesign things, you know, maybe move some responsibility there, some other responsibility here so that the design of classes make mocking a little bit easier.

That’s number one. Number two is I feel like sometimes we have this idea that if we’re using mocking, we should only test one class and then. And that’s not really true, right? Maybe you can test a bunch of classes together and just mock the classes that are, you know, super hard to use the concrete ones.

So you can test higher components and some classes are the, you know, the concrete implementation during the test, some other classes you just mock. So I feel like you can also try to, you know, go one level up and look at, you know, classes together rather than one single. That being said, some domains just are not unit testing friendly.

And the domain mentioned mining reposts is it’s one that is super close to my heart as well as a researcher. And so when I’m doing these type of tools, where I extract data from V3 post threes, or I bar source code to come up with code metrics I don’t try to unit that so much. So I have a, I have a project in my get hub called CK, which is the code metrics tool.

It looks at the Java class and tells you the complexity, coupling and et cetera. I don’t mock. Because it just makes no sense. It was super hard for me.

So 90% of the tests there are integration tests. So there’s also, you know, these type of domains where you should go for integration tests because they will pay better.

[00:23:37] Michaela: Yeah. Yeah. I think that’s a very pragmatic answer. I like it very much. I also, in this, in this kind of situations I haven’t. Rely on integration tests, but I actually also ride a lot of unit tests for things that are easier to unit tests.

But if I see that it’s really hard now, I change my method and do something that I feel, is a little bit [00:24:00] more meaningful also from a maintains perspective. Right? So. Maintain ends, I think is also something. And maybe something that I want to talk with you about tenants, I think goes hand in hand with Tesco because we have to maintain Tesco, right?

If you don’t maintain it, and if it’s really hard to do it, we are not doing it. You are disabling the tests. I know it. I did it right. I At one point, you’re just giving up on it and to say, okay, already commented out or I deleted, or the worst thing is common to the alt-right.

So I think Ventana, the tests are so important. Do you have some tips for us how to get to maintainable tests?

[00:24:32] Mauricio: My book proposes 10 guidelines. I of course don’t know them all by heart, but the, they are all about readability, maintainability of Tesco because in practice you’re going to write lots and lots of them.

So my generic advice there that encapsulates those 10 recommendations in the book is you should pay as much attention to the test code. As you pay to production codes. We love to refactor. We love to create abstractions. We love to isolate the code. The same techniques you can apply in your test code and that will pay off for sure.

Finally, Michela, you mentioned you mentioned flaky tests, those really happen. And we should try to avoid them as much as possible. Although I just wrote a blog posts on the website of my book saying that I don’t believe we can ever get fully rid of them, because if we’re in a super large and complex system they will happen.

And sometimes for reasons, you can’t control for reasons you don’t fully understand. So I feel our job is to not only avoid them when possible, but also to keep them under control.

[00:25:41] Michaela: One thing that comes to my mind is when I was working at Microsoft what we did, like windows had flaky tests, right? Especially because the integration tests and the functional tests where we really try, you know, under different settings, the systems and so on.

Blah, blah, blah. Right. So it gets really complicated. It’s really, you know, a lot [00:26:00] of configuration, so you’re running a lot of tests and some of them just fail. And so what we did here is we, instead of, you know, sad, well, let’s, let’s disable all the flaky tests or, you know, it wasn’t even possible to fix all of them, right.

Because it was sometimes. Clear why there, you know, why they’re flaky. And sometimes what we did is we measured their effectiveness. So how often is it flaky tests actually finding a thing? And how often is it giving a false positive? And we had like a cost benefit analysis where we say.

Well, every time it fails for no good reason. It’s a cost of your career because we have to go and investigate and find out actually nothing happened. And then for every time it actually finds it back. We tried to estimate. You know, how much did that actually help us now? Right. So how much how much did we safe and so for each of those tests, we had a profile on, you know, from past runs and we looked at that, I mean, it was again, obviously an automatic approach.

But again, test case comprehension. So what we provided office, for example, with, and we worked with windows was these are your test suites, right? These are the test cases. And this test, you know, is more red than green, more red than green means, but it’s failing really often. So you have to investigate really often and, you know, you just realize nothing happened.

And it actually doesn’t really find anything. Right. Or the other thing is, well, it fails quite a bit, but it also finds quite a lot of things. So we still think you should keep it or, you know, go and improve it and so on. So yeah, this is something that came up from my mind when you were talking about flaky tasks is that something that you have ever looked at?

[00:27:41] Mauricio: Yeah. So all big software has flaky tests, right? And agile is not different. So there are some flaky tests there. And the approach that the engineers have is super smart in my opinion. So they first detect the flaky tests. If the test is freaky, the first thing that happens is we move these two separate.[00:28:00]

Right because we want to keep, you know, one test suite free of flaky test. So this one we can run and we can trust. And then we have a second test suite where we, we have the flaky tests, so there, and we keep trying them more than once. If they pass, we are somewhat okay. And without the developer, you know, this is flaky, but it’s sometimes specialist, please review.

We tried to see how often it is flaky. Right? So the developer has more information to understand it. But what I think is super smart is the separation, right? So we don’t want to, because if you have flaky tests and then you break the build because of a flaky test, you’re breaking the entire organization.

Right. And you don’t want to do this. So separating them from, from the tests that are not flaky, something super smart. The project does. Yeah. That’s very cool. Yeah. Yeah. So I feel like as soon as your software gets that big, you’re not going to be able to avoid flaky tests. So you have to learn how to live with them.

And I wrote a blog post about some smart stuff I saw not only at adjunct, but in industry in general, we have to get used to them. The more complex we do software, the more we’re going to see.

[00:29:06] Michaela: . I will link that in the show notes. So Maricio maybe the last thing that we want to let our listeners know again, is that if they go to , as the underscore unlocked on Twitter and retweet this episode, and then you have a chance to win this awesome book from a ratio about systematic software testing.

And if you add a comment about. Practice in testing software, then, you know, you’re a double in the pod, right? So there are two entries of you in the pot, so you have double the chances to win in the book. And so yeah, with that thank you so much. Mauricio I think it was a super great interview. I learned so much, I heard so much from you.

And I think my listeners as well, so thank you so much for being on my

[00:29:46] Mauricio: show. Thank you, McKayla again for the invitation. I loved it. Yeah, it

[00:29:51] Michaela: was really great. Okay. Bye. Bye.

[00:29:53] Mauricio: Bye.

Driving innovation and engineering practices with Dr. Holly Cummins

In this episode, I talk to Dr. Holly Cummins. Holly was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail, or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author, and a regular and vivid speaker. 

We talk about:

  • What it takes to drive innovation in an organization
  • Test-driven development (TDD)
  • Ensuring a healthy and welcoming company culture
  • The benefits of Pair programming

This episode is sponsored by IBM – where innovation and transformation come together.

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


[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. Mckayla and today I have the pleasure to talk to Dr. Holly Cummins. This episode is sponsored by IBM. IBM not only produces and sells hardware, middleware and software, but also offers hosting and consulting services. The part that is the most interesting to me, is that IBM is also an active research organization, and an enabler for innovation and transformation. One interesting business area is called the IBM garage – which focuses on accelerating digital transformation, by helping people generate innovative ideas while it also equips them with the practices, technologies and expertise needed to rapidly turn those ideas into business value.

Dr. Cummins was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author and a regular and vivid speaker. So what should I say? I’m super thrilled to have Dr. Holly Collins here with me today. Holly, welcome to the show. 

[00:00:56] Holly: Thank you so much. It’s yeah, I’m really looking forward to our chat. 

Michaela: Yeah, me too. I mean, my introduction was really, really long because yeah. You have so many accomplishments. It’s really cool to talk with you. So how does that work? Driving innovations for organizations? Can even one person drive an innovation for a whole organization? Or do you need like, that everybody is on board. How do you. 

[00:01:21] Holly: I think one person can make a whole organization innovate, but one person can help create an environment where innovation flourishes. I think we’ve certainly all seen the opposite as well. One person, if they do it wrong, can really best innovation across the whole organization. And I think. With innovation. It’s about making this sorts of environments where ideas can grow and where there’s the second, the logical safety for people to express ideas, but then also the organizational tolerance for risk too, to be able to invest in those ideas. But then also I think you need some methodology or, or some rigor to try and. Manage your innovations, because I think a lot of us have as well have seen innovation labs where there’s all these amazing ideas and then none of them actually make it out the door of the innovation lab. And that’s fun for everybody, but it’s not really moving things forward. And really what you need is innovation that matters. 

Michaela: Yeah. . I’m currently working on a research project where we look at cultures, especially for development teams. How do they have their cultures? What makes them happy? What makes them productive? What makes them innovative and psychological safety and, you know, being able to speak your mind. This is also important. And I conducted a couple of interviews. I also have worked in different organizations and it’s just really tricky, right? I mean, it’s really tricky to be in a work environment and being able to voice your opinion. And some people get really lucky, but a lot of people really struggle with that, I think. And I don’t know if it’s, if it’s bigger organization, I can’t, can’t even say like a bigger organization. It’s more tricky than in, in smaller. I’ve been in startups. So you think, well, innovation should really flourish down. There were like brilliant people on the team, but they’re are also. They take all the space, right. They’re very dominant people. So then all the others conferee so much, then there are like larger organization where you can strive. Is there some recipe that you can recommend for people to, you know, follow to get more psychological safety or do you know, be, be more self-aware if others even can speak their mind or, you know, like, how does that work? 

[00:03:40] Holly: Yeah, that, that that’s yeah. Super interesting about the startups. I I sometimes feel at a disadvantage talking about culture cause I’ve worked for IBM, my whole career. And IBM clearly is not a startup. It’s about as opposite a startup as, as you can get in terms of its history. But one of the things that I. Like to talk about, which I think is probably quite related to your, to your research is the importance of fun in the workplace. And I deliberately talk about fun because it’s a little bit provocative because we all have this sort of instinctive reaction that says work is a place for work. It’s not a place to have fun. And so then. I think by sort of choosing something that seems counter-intuitive and then peeling away the layers to talk about why actually that fun environment is really closely correlated to a productive work environment. And I think as well, it’s, it’s quite closely correlated to psychological safety. And I think, you know, the psychological safety manual, certainly doesn’t say let’s have achieved psychological safety by, you know, installing. Ping-pong or, you know, that kind of thing, but, and it’s, you know, and I think what I mean by fun as well, it’s not those sort of that superficial layer of fun. It’s that, that deeper thing where you feel the connection to your colleagues and you feel the work gives you joy. 

Michaela: Yeah. I also saw that coming up in my own research, but also related research, right. That satisfaction, happiness and productivity. They are really concepts that are very intermingled. ? So engineers also having fun if they are feeling productive and productivity also means connectiveness. ? So a lot of developers that are interviewed, they talk about supportiveness and how they have to know that there is another person that I can. Call or no call before we could walk up to them, but now we call them and they are there and they’re helping us. If you’re stuck, we don’t see the siloed. Right. There’s a friendship coming up as a concept. Right. People want friendship in their workplace. Yeah. I can totally relate to that. I felt really lonely last year working as a solopreneur. And so that’s also why I stepped a little bit away and was taking on more customer work again, because now I’m in teams and I’m feeling, you know, I’m talking to people more and this is really, I mean, it’s also joy and yeah, so I can totally relate to that. How, how do you engage with organizations? So you are at IBM, but you got into different other organizations or is that all internally where you have like little labs that you, you know, that you try to get to flourish? 

[00:06:09] Holly: So my role at the moment it’s somewhat internal and somewhat external. We’re always working with clients, but sometimes I’m working with an IBM team who is working with a client, but in, in the garage we were, we were very outward facing client facing. And, and I think there’s, there’s lots of different answers for how do you engage with an organization? How do you change an organization? Right. The, the answer that we chose in the garage is really sort of support at the top and then making the change bottom up. So we would try and get buy-in from the senior stakeholder. And the organization wanted to try working in a new way that it wanted to try bringing some of these, the psychological safety in the innovation. But then also some of the other things that we talk about a lot, like, I mean, agility is an overused word, but that, you know, that ability to respond to change that, that tolerance for risk. But I think sometimes know. If if we try and make that change only at the top level, then it just ends up being as a lot of words on slides and so in. And, and there’s a lot of resistance to these ideas as well because people work in the way they work for a good reason. It’s not like everybody’s sort of set out and said, I know we’re going to make our organizational cut culture so that it, you know, crushes the spirit and destroys productivity. You know, the intention was always to, you know, to try and achieve something good. It’s just that the side effects. Yeah. We’re not good. So then what we do is we work with a particular team on a particular project, and we say, we’re going to, we’re going to do this particular thing and we’re gonna get a result and we’re going to do it in this new way. And you can see that while we work in this way. Actually good things are happening, not bad things. And bringing in dev ops, for example, hasn’t increased the, the odds of something bad happening. Look, we can show you it’s reduced the odds of something bad happening, and look, it’s actually made the process more rigorous, even though the process is also more seamless. And so if we can do it on this one project, that’s maybe not super business critical, let’s try and now expand it to the next project that maybe is a bit more business critical. That, that ripple I would affect because I mean, I think success is the best evidence. And so when you can do something and show the results, then that makes people much more keen to try it for themselves. 

Michaela: Yeah. So you are coming in and then you’re working with one team. And is it only you, or is it you and the team that’s working with that other team with that project? How does that work? 

[00:08:41] Holly: Usually we’d have a team. And I think the, sort of the, at that teamwork aspect is, is so important. I think going back a bit to what you were saying about the lockdown that even the most introverted developer, I think, you know, we, we get something. Team and the, the effects are much better as well. So we try and have really diverse teams in terms of the skills and the disciplines of the people. So normally what we would have is we’d have a handful of developers. We’d have maybe some, some architecture support. But then we’d also have designers who are really making sure that we’re focusing on. The humans using the technology rather than just look, it’s a thing and it’s shiny and I can install it and I can write code on it. And so I’m happy, you know, trying to sort of reel it back, but I’m glad you’re having fun Holly, but how are we making life better for someone else? And, you know, what’s good. You know, cause success for any software project. It’s not just, I did code success is something is better somewhere either at a business level or, you know, at a user level or that kind of thing. So on, on our side, we try and have this really diverse team, but then we also want to make sure that we’re co-creating with the client. So our ideal is that they’re bringing their developers along. They’re bringing their architects along. They’re bringing their designers along as well. And then they’re bringing a product owner because they’re the one who owns the vision for what we’re trying to do. And then that means that as well as making the thing we’re doing a skills transfer. And so I when I was first working in the garage, one of our, the the IBM sellers who we were working with got a bit grumpy because the, the sort of model that they had done was that we would do a thing and then they would sell training for the thing. And because we were. Co-creating that training just sort of happened on, on the job and it didn’t slow anything down. So we would be pair programming and that knowledge transfer would happen. And it would happen in both ways as well. So we, we know things about the carriage method that we can share. We know things about test-driven development dev ops, but then, you know, they’re going to know things. Or organizational context to say, ah, yes. When you want to do this, you need to tell, talk to Bob on the second floor. And so having the person who knows that pairing with you means that you don’t sort of have to go through this elaborate process of I’m stuck. Who do I talk to you? And then, you know, try and figure it out. And they know things about their, their business domain as well. And you know, the sort of the, some of these problems are really quite specific and niche. And, you know, you couldn’t have just a general consultant go in and solve it without doing that. Co-creation. Yeah. 

Michaela: And how long are those engagements normally until there is some transformation and some knowledge transfer, how long does it take 

[00:11:31] Holly: for the license? I don’t think the sweet spot is about six weeks, so that’s, that’s long enough to do something that’s really meaningful to get an MVP, but it’s short enough. That an organization will feel okay with the risk. Cause, you know, if we, if we sort of say, and, and, and as well, you want to make sure that at the end of it, those results are going out and are really visible. So having that short cycle and then say, okay, and if we’ve done it once and you like it now, let’s do it again because. You saw that result and it wasn’t this sort of really protracted process where it took 12 months to see any change. Yeah. 

Michaela: So you are mentioning already a couple of development practices, like Def ops test driven development, and you have, I mean, the development practice lead for IBM garage. So. Do you think, what are some of the development practices that you recommend that really everybody should do? Is it like peer programming? You also mentioned that or code reviews. What about testing? Do you think this is crucial? Do they have to do it? Can we just do it a little bit? Or can we just skip some of those things?

[00:12:40] Holly: Yeah. We sometimes have conversations about testing because. The there’s a trade-off I think between doing something quickly and failing fast and getting that rapid feedback and not over-engineering while you’re doing that and the enormous benefits of testing. So sometimes if we’re doing something that we know is going to be throw away, and I think there’s a lot of value in doing something that you know, is going to be thrown away. That is that, you know, sort of lean startup , methodology, maybe testing doesn’t make sense. But I think in general, The, the benefits of testing are so great in terms of the quality of the code, but also automated testing is absolutely necessary to support dev ops and dev ops is really. Necessary now in order to support any kind of automation and efficiency and any, you know, that, that ability to do those repeated deployments and the ability to respond, to change and to manage risk. Sometimes, you know, you sort of hear these stories of something that goes wrong and then an organization doesn’t have any way to make a change to fix the problem, except either to go through. Lengthy process or to completely short circuit and bypass the process and, you know, have someone secure shell into the effective machine. And then they change the things by hand, which is obviously not going to be particularly robust in terms of the repeatability or the safety or anything. So you sort of get this chain where you. Do dev ops, because I know it gives so much better results in order to do DevOps. I need to have automated testing. If I’m going to do automated testing, I want to do it with test driven development, because that gives so much better quality for the tests and it. ensures the testability of the code and as well, I think one of the biggest benefits of test driven development is really to refine our understanding of the problem as well. Some people call it tested and design rather than test driven development because of that effect that when I sit down, I think we’ll see, what am I really trying to do? How will I really know what I’m successful? Let me write a test for that. And usually what we look for with a test is something that we would have been looking for manually. Anyway, you know, I go to a web page and I see this, or it prints this. It’s always, you know, we’re always looking for some evidence. We just try and encode that, looking for the evidence in, code, which is efficient. Usually. 

Michaela: Yeah. So test driven development often is I see it a little bit synonym to also unit tests instead of integration tests. But now you also mentioned something like a UI test, for example. So do you have, like, do you make some distinction here and do you think one is better than the other? Do you see that there’s a shift nowadays in industry? I see a shift and a little bit that, what is your perspective on that? 

[00:15:33] Holly: Yeah. I mean, I like to do test driven development at, at all levels. So I like to do test driven development for my integration tests. I like to do test driven development for my unit tests. I think sometimes you do get a little bit tangled where you can’t have, you know, you sort of, you, you do your, you write your unit test and then it passes. And then in doing that, you’ve done enough that actually your integration tests is already passing. So then you’re. Catching up with your integration test a bit, but sometimes we do it the other way and we say, okay, I’m going to start with my integration tests. I’m going to get those integration test passing. And then I’m going to fill in a bit with the unit tests. But I think like, I don’t think it’s something that is just for one level. I think if it’s an outcome that you care about and that you don’t want to regress, then there should be an automated test on it. I mean, I, I. I’m a huge fan of contract tests as sort of an intermediate layer between the integration tests and the unit tests. Cause I think sometimes with unit tests, well, integration tests are really expensive to run in any kind of complex environment, especially once you’ve got 60 microservices. Good luck running the integration tests in any kind of regular way. But then with the unit tests, I think you can sometimes get the sort of abdication of responsibility where everybody owns their microservice and they run their unit tests and everything works great. And the system as a whole doesn’t work. And so somebody has to care about that at some point, but then you sort of end up playing this sort of. Sort of pass the parcel of responsibility, where everybody goes more, my services working as designed. And so then an on all the problems happened at the seams. 

Michaela: Yeah. , my PhD thesis was about playing in testing our plugging systems and how you test them. It was more or less also services, service oriented architectures at that point. Right. And it was pretty new. People were just jumping on that vegan and so on. And I said, well, you know, you were going to get a little bit into travel if you’re, if it stayed the same with how we are doing testing and nowadays but you’re also an expert for cloud computing. Would you say that in the cloud world, somehow testing or in general engineering practices change, is there, do we have an impact we should we or can be developed in a different way, test, deploy everything. Why is said the same? 

[00:17:54] Holly: Yeah, I think it has to be different in order to take advantage of the cloud. So one of the things that you’re almost certainly going to want to be doing on the cloud is, is that DevOps it’s that more rapid deployment. And then if you. Deploying rapidly. And you don’t actually know if your code works, then either you’re going to have an enormous issue in production, or actually you’re not going to be deploying rapidly, you know? So we still sometimes see these cycles where something is getting deployed to the cloud, but then there’s a three week UAT phase before anything can be deployed. And so then. You know, that just doesn’t work. It’s a waste of the cloudiness. It almost may as well be on-prem. So, so you sort of get this ripple back from, again from the dev ops, which you want to be doing to the testing to the TDD. 

Michaela: I also think like we had, we had very strict roles back then. Right. So whatever, like operations. Yeah. The engineers, the software engineers or developers. And we had like the testers, then there was like a time. Now we have this dev ops for, you know, at one point for dev ops, I feel like every engineer was supposed to be a dev ops engineer. And and then we had like the full stack. So you’re not a front end or back end, your full stack, your full stack from front end to back into dev ops to everything. And now I feel people start to struggle with that concept again. No everything because there’s so much to know that there’s not a single person that can be like this end to end dev ops engineer to front end you know, genius. You see dad, like is there, is there again do you see that there are more roles that are forming itself or a person is bringing more Def of engineer and then more of backend, more front end, you know, cloud maybe, you know, even more concepts that we have here.

[00:19:43] Holly: Yeah, that one’s a really tough one. And I, yeah, I sometimes sort of, and I think I sometimes talk to people who ha, who say exactly the same as you, that, that there are too many expectations on me and actually trying to do all of these things means that not only will I not be quite as good in all of them, actually, I’m going to be pretty inadequate in all of them. And are you sure that’s what you want? And so. I think there probably is, is a space for having those specialist roles. But I think part of the issue as well, sort of is there’s an organizational decision about where do you, where do you put the boundaries? Because I think we probably still do want to be saying. That if you are too specialized, it creates organizational friction because it means that you risk becoming a bottleneck or, or the opposite as well that it, you know, it means that you risk not being deployed because all of a sudden, none of the projects our organization is working on, have a need for your skills. And since you only do this one thing really well. You’re just going to be sat around and that’s not great for us cause we’re paying you and it’s probably not great for you either because you’re really bored. So let’s try and have everybody at least be able to do a few things and let’s have people really comfortable sharing their skills as well. Cause I think that comes back a bit to the pair programming and the multidisciplinary teams that maybe I’m pretty sure. Pretty bad at front end, but I know just enough front end that if I’m collaborating with a front end developer, I can bring my something else. And we’re still going to do a better job than if that front end developer was on their own. And we’re going to do a way better job than if I was trying to be a front end developer on my own. And so then you get these sort of complimentary skills in, in the pairs. 

Michaela: I think we are coming back again to the teams as well, or to the concept of a team. And that people are really strong as a team. Maybe they are. And there was like, I did an interview with it, very senior engineer. And what he said is like, , if you want to go fast, go alone. But if you want to go far, go with the team or with people. Right. And so this was indeed in one of the interviews about productivity and happiness and so on. And I think. I was also talking to Alex from FedEx and she was on my podcast. He’s a testing expert. And she was also talking about these teams where you have like a person that has a strong expertise, but then this expertise somehow overlaps. Right? So you want to expand your expertise to other roles. Let’s say you are a testing expert, but then you want also to understand development a little bit, then you want to understand maybe dev ops a little bit. Right? And so you’re having this. These shapes that are overlapping. And then in the same team, you have a person that is very similar to what you said, right? They are front end expert. And so you’re overlapping in your understanding each other quite a bit. Right. It’s good. If you don’t, if you’re not solely responsible for everything and you can learn from each other, I think learning is also such an important concept for happiness. Do you see that, that people want to learn? 

[00:22:47] Holly: Yeah. A a hundred percent, I think it’s, it is one of those things that motivates you at work. Isn’t it is, is that desire to learn and, and, you know, if you just do the same thing every day, it, I mean, it’s, it’s awful. Isn’t it? There needs to be something coming in. And I think you’re right. That, that does come back to that teaming that if you’re working in a team and people have different skills than you, then you’re, you’re automatically going to be learning. And one of the things that I always said about pairing in particular is, you know, there’s sometimes we put sort of a hierarchy on pairing doughy and we say, okay, so we’ve got the senior developer pairing with the junior developer and they’re teaching everything they know to. It always, it always goes in both ways. So as a senior developer, if I’m pairing with a junior developer, often they’ll know a framework I’ve never heard of. And so then they’ll teach me about that and they’ll know keyboard shortcuts. I’ve never heard of. So they’ll teach me about that. And so it’s always that, that two way knowledge transfer in, you know, independent of your position in the hierarchy or how long you’ve been anywhere. Yeah. 

Michaela: So I hear you talk a lot about pair programming, so. I don’t hear you talk about code reviews. What do you think about them? Do you do them, are they not that important? Do they compliment or do you don’t need them, if you do poor programming, how do you see 

[00:24:03] Holly: that? So my, my, my personal take is that one of the great advantages of pair programming is that it eliminates the need for code reviews. And we sometimes talk about You know wait, isn’t pair programming, more expensive. I’ve got two people doing the work of one person and, and, you know, there’s all sorts of reasons why that’s not true, but I think one of them is that otherwise you have, usually you will have a para-pro code review process at the end, otherwise, and that can be really expensive, so it can be expensive in terms of people’s time, but then it can also be expensive in terms of the sort of thing. Bottleneck and the blocker that it creates, and it can be expensive as well in terms of the, sort of the patterns that it encourages. Because if people know that when you put something in for code review, it takes three days to get it back and get it approved. You know, that’s maybe a pathological case, but it’s not that pathological people. Aren’t going to be putting things in every 10 minutes. You wait until you’re finished something and then you send it over and then you get this. Spiral where the person who’s doing the code review gets a mountain of code and they go, Ooh, I’m not, I’m not looking at that until I’ve got a bit of room in my schedule, which is three days later. And then as well, when they look at it, usually. I see a couple of things happen. One is that because it’s so much work, if there’s a really fundamental design problem, either it’s sort of too late and they can’t see it, or they do see it, but they think, oh man, you know, they’ve been working on this for three days. I can’t go back and tell them they should have done something completely different or that they shouldn’t even written any of this code. And so then the sort of the big problems don’t get fixed and. But then you think, well, but I’ve got to show that I did the review. I’ve got to show that I’ve got some value in this process rather than just annoying them by waiting for three days. Let me find the position of the semi-colon line 36. Let me comment on that. Then everybody knows I’m contributing. So you get this sort of bike shedding. And as you can tell, if I find the whole, the process for us one of the patterns that I really encouraged with the pair programming is that you rotate the pairs every day. So that gives you a much deeper code review. Cause I think otherwise you only, you get like one person’s code review, but then you sort of end up where two people can be wrong just as easily as one person or two. Certainly, you know, two people can be wrong. So then on the second day, A third person comes in and then there’s already sort of another built-in code review where they, in order to be able to contribute, they get walked through what was done the day before. And then they’re able to say things like, oh, well, but why did we do this? And here, why don’t we just try this? And it it’s, you know, it’s not a formal review. It’s an interactive sort of getting them up to speed teaching experience, but then it means that there’s this second chance to catch errors before. Developed too much, but I think, I mean, I think you probably are. You’re asking the question cause you, you probably have quite a lot of expertise on code reviews and you’re gonna tell me all the patterns where it does work, which of course it can, then it can work 

Michaela: with no, no, but I definitely did the recall and realize all the things that you said, because this are definitely really common problems that I also see that teams have. Right. So this is also one of the things by in my view, Teams come and they bring all really everything that you said, right? Like, and this whole chain of how it just doesn’t work. Great. How to process doesn’t work and where you, where you have this waiting time, where then the code reviews are too big, right. Or you’re done, cannot understand them. You still have to do them. What do you do? Right. So this, there is definitely this, this loop that you are describing. Totally recall, because this is, you know, this is the, the problems that all the people are bringing on the table when they’re coming in, when I’m working with it. Maybe what I see, I actually really liked code reviews because of this synchronicity. Right. So you can have them in a very lightweight way. I also see them complimentary a little bit to peer programming, but you definitely have to do them in a different way. Right. And I think what many organizations don’t understand and why we are creating this loop of yeah. Troublesome problems that we have, how we doing is that we don’t understand the goal of why I’m doing this. Right. What do we want to get out of that? And then also, okay, what do I want to get out of that? And how can I shape the process in a way that I’m getting this out of that? Because I really see that they have all these painful drawbacks. Definitely. But they also have like really wonderful benefits. So I think the most important is that you really understand. The pain points that you said very, very deeply, but then also, what can you, you know, what can you do to counteract them? How can you change your practice but, but I see, I see all the things that you say, and I’m actually a big fan of pairing as well. For me personally it’s very draining to do it. Like I love it from time to time, right? Like it’s the best where I feel like. You have your mentor there, or, you know, you have just this connection and the supportiveness with the people. So I totally enjoy it from time to time, but not too often. How often do you do pairing? 

[00:29:17] Holly: So what, what we used to do. In the, in the garage is, is we would do it pretty much all day, every day. And there was, there was a few advantages to that because I think one of the, sort of the hardest things of pairing is the logistics. And so then going back to the PA to the code reviews, you know, there’s some circumstances under which pairing just will not work and makes no sense because it’s, it’s so synchronous and asynchronous doesn’t scale. So, you know, you need to have that kind of asynchronous process as well. And if you’ve got Particularly, you know, if it’s something like open source where people are in different times zones and they’re working different schedules and some of them are doing it in their own time, you know, something like pairing it, it, you know, it’s almost off the table to, to begin with. But what we found is if we tried to be. Ad talk with our pairing, which of course works quite well for a lot of teams. We sort of, we never ended up doing it because it would be well let yes, let’s pair today. Yeah. We definitely want a pair today. Okay. So, so maybe after lunch. Oh, I can’t after lunch, I’ve got, you know, I’ve got a thing. Okay. Well we’ll maybe, maybe at two o’clock. Oh, I can’t. And then, you know, we, we settled that we’re going to start pairing at three o’clock, but then something would come up and then somebody would be unavailable. So by sort of defaulting to pairing, we’d keep our calendars free. And it was great actually, because if we got invited to. I’m afraid I can’t attend this meeting. I’m pairing. So if you interrupt me, you’re interrupting my hair as well as it was sort of, it was like this sort of intro we could block your time. 

Michaela: a couple of organizations that are working with and That we try something out and it looks really, really nice is that you’re doing code reviews on a particular time. And then it’s done by one engineer. Right. But they’re doing all the others can go in and now everything is via suit, right. As are our teams and whatnot. Right. So by that video conference, and so they’re doing this cultural view, right? Everybody that’s interested can join. Right. And those sessions really, really particularly work well. I’m very surprised by that, but I really have good feedback from, from different organizations where you know, you have this casual thing where people know this is happening, right. One person really drives the review and the errors can watch ask questions, clarification questions, or, you know, other things maybe learn just have their fairness. Have you tried something like that? Is that 

[00:31:36] Holly: we’ve tried some similar things? Not, not exactly like that, but that, yeah, that seems, seems really good. So we did I mean, one pattern of course is the sort of the mobbing pattern where we say We don’t just want to do it with two people. We actually particularly for knowledge sharing, you know, we want to do it with six people. So let’s all gather around the keyboard or let’s all gather on the zoom, but as well, what we used to find was, again, it’s that scaling that the pattern I described, where you rotate the pairs every day in a big code base. With a big team is still gonna be quite a while before you rotate round. And so then you do need something else. So what we’d sometimes do is on a Friday, we’d do a show and tell session. So it was, it was very similar to what you described actually, but we’d sort of someone would say, okay, well, I’ve just done this particularly evil thing in this part of the code base. And nobody’s sure. Yeah, understand what I’ve done unless I talk them through it, or I’ve just discovered this really counter-intuitive behavior in this library. Let me show you all what it does. So you don’t get called out the same way I did. So it was sort of partly a code review and then partly a, an education session, but it would just be really informal and just whoever had interesting code. Would show it and talk it through the rest of the team and then they’d ask questions and that kind of thing. 

Michaela: So maybe one last thing that I would like to talk a little bit with you about is because you. You actually transitioned a way, right? From, from being this development lead at the IBM garage. And now you’re an innovation leader in the corporate strategy team. What does that mean? And what, what’s your role there? What do you have to do? 

[00:33:05] Holly: So our, our, my role in corporate strategy, it’s really interesting. It’s because I’m sort of in the, you know, we’re sort of a headquarters role, so I’m sort of in the, in the heart of IBM in, in the center of IBM and I sort of get to see a lot of what’s going on and what we’re trying to do is we’re trying to. Really just be the, sort of like a free resource, both people and financial to try. And when we see something amazing that can’t quite happen because there’s some sort of blocker or there’s just, you know, it just needs a little bit of money to, to get over a starting line that we can sort of give it that, that push. And then hopefully. Make something amazing happen so often it’s where if we have a client team and you know, the client really wants to do something and we really want to do something, but just somehow it just needs a little bit of money just to demonstrate to the people who have the large amounts of money that this is really worth doing. And, and one of the things that we do as well, because I think as an industry, we’ve, we’ve moved a lot now, too. Every, you know, we always want to be trying to do things by actually trying them out rather than doing slides. So that that’s not, it was new when the team I’m part of was started. It’s not, it’s not new anymore, but still in a larger organization, you still sometimes get things that fall between the cracks where it doesn’t quite fit in, in anybody’s mission. But that means it’s actually extra important. So then, because, because we’re sort of central, we can bridge those, those internal barriers. 

Michaela: And do you still have a lot to do with engineering? Do you still develop software or is it more really strategic and leading that you’re doing right now? 

[00:34:49] Holly: It’s a little bit of a mix, which I think going back to what you were talking about with the learning and the, and the variety, I think it is good. So it means that whatever, whatever seems most necessary. We’ll do that. So sometimes it’s actually let me go in and architect this, let me, let me go in and out a bit of code. Let me, you know, I’m not a data scientist, but some of my colleagues are data scientists and they’ll okay. Let me fix your model for you. And then sometimes it’s more strategic and more making those connections to say, actually, I can see that this is going on in one part of our organization and something complimentary is going on in another part of my, let me connect those two, and then we’re going to get a better outcome. 

Michaela: Oh, that sounds like you’re really having a lot of hats. I really liked that when I was at Microsoft, also driving bit innovation there and having all these different hats, like you’re, you’re driving projects, but you’re also doing the implementation. I was mainly prototyping at that time. But it also means that you, as you said, you have to learn a lot. Did it take it a little bit to get used to that role and know what you have to do? Do you have like mentors that help you or is it. Structure around some, formal mentorship program at IBM. How does that work? 

[00:36:03] Holly: I think. With that kind of role where, where you have a lot of hats. I think it comes back to, to the team again and the sort of the resiliency and the team. So what we tend to do, because we’re doing challenging things and we don’t know in advanced necessarily what skills will be required is we, we do sort of go around in groups where there’s more than one of us. And then that means that whatever hat ends up being needed, there’s someone who has that hat and then someone else who can sort of shadow the hat. 

Michaela: Yeah. Yeah. That sounds really a great team to be in. Maybe the last thing really last thing. And then I’ll let you go. Or that I want to talk with you about is there’s the same culture eats strategy for breakfast, right? So, and what it means is that. The culture is of utmost importance. But also it’s a very vicious cycle that, you know, how do you get your culture to apply and how do you get your team members to, you know, like each other or at least respect each other, right. Especially if you have, so sometimes people have I also have that in my workshops when we are, you know, when we are working on these problems, that code reviews create right where we have, for example, very strong personalities in a team with very strong opinions. So it have problems, you know, like giving into, what did you hear? Do you have like do you have like some strategies for that? Do people do something to do, do some coaching or can you help can the team help itself? What’s your experience with that? 

[00:37:34] Holly: It’s. It’s tricky culture, because in some ways, some things about culture, you, you can change because you can, you know, sort of start with your small changes and then success is the best evidence. And then you can roll it forward and you can make those little changes to encourage psychological safety. And you can have, if, if the leaders are bought in, then they can make some of those changes as well. But part of it then does still come down to the people in the team. And that is often the thing that is. Most challenging to, to change, but, but even, even people I think are, are changeable. And I think sometimes characteristics that we assume are just this person actually are the context in which we put them as an organization or habits that they’d learned that with the right environment can be unlearned 

Michaela: or teamed up that makes maybe right or one person creates or reacts, but only two, right. Person, but to really the whole team dynamics. Are you are you a fan of like bonding sessions and you know, we’re people, what a team really can, you know, get to know each other, do you think that’s 

[00:38:45] Holly: I really like them, but I think they, they need to be done sensitively because they do end up sometimes not being very inclusive if we. If, if we choose something that half the team love, and then some people are sort of stood there going, well, this isn’t really what I wanted. So I think there sort of needs to be some, some pre-thought to, well, there’s everybody in the team going to like going out to a noisy bar or. Does that actually not work. And I’ve seen I’ve had some good conversations with people actually, when I talk about fun, because sometimes we get these sort of bonding sessions that get put into a team and we say, right, we’re going to have fun. Now we’re going to, you know, do our bonding and we’re going to go out to a bar and some people are going to know this, this isn’t fun for me at all. But then there can be alternative. So some teams, for example, they’ll play a board game at lunch. And so it means that people who need to rush home after school, you know, are after work to get kids from school or that kind of thing. You know, they’re, they’re included and people who don’t drink are included and it’s in sort of at work. So then it feels like an extra nice treat. It doesn’t feel like you’re sort of being required as part of your job to go out and do things out of hours, which some people really object to. And so then, you know, and there’s other things like, like that, or. This is a really old example because w w one of the other things that happened when I started talking about fun is lots of people told me about their workplaces and that the terrible unfun things that had happened. And there was a team and they were sort of there were a support organization, so they would work quite long hours and shifts. And it was a distributed team. So what they would do is AF after five 30, they would all play quake or doom or something like that together. And it was sort of back in the day when broadband at home was a luxury. So you would take advantage of your office network and they were, you know, they were, it was completely you know, a bonding thing. And they were told by management, if you’re in the office after five 30, you have to be doing work, which I just thought was. Incredibly short-sighted on the, on the part of the, that management to say, you know, your, your people are not on your time making the effort to get to know each other better and to work better as a team. And not only have you not, you know, encouraged this and, you know, put in money for cakes or something, you’ve actually told them they’re not allowed to do it. Yeah. Yeah. That’s very, 

Michaela: very shortsighted. Yeah. Terrible mistake. But sometimes I really like for management, sometimes I really ask myself. How can you make this decision, but you know, different story. Okay. Well, Holly I know we are on time, so thank you so much. I could have, you know, like talked with you another hour, but thank you so much that I could pick your brain about everything, about all your experience and you know, your knowledge that you have. Yeah. It was really wonderful that you have been on my show. Is there something that you want to share with my listeners? Did you think it’s important for them maybe around culture, happiness, fun productivity, maybe a little thing that they can start doing today? 

[00:41:49] Holly: I mean, I th I think, yeah, just to sort of think about those, those, those aspects of fun and, and think about how can I have more fun at work? How can I bring more joy, joy, and delight at work, but also how can I make. Those around me are also having more, more joy into life at work because otherwise it becomes a bit one-sided. Yeah, I 

Michaela: think in general, after Corona, I call it now after COVID right. I just say after, because it’s just nicer to say that I think we really have to come back to thinking more about others. I think we haven’t been thinking. Enough about others before, but I think, I don’t know how it’s in, in, you know, in the UK, but it, at least here, I feel people are more distance because of it. Right. And I really think we should think more about each other and you know, what brings us joy? How can we help others? How can we be nice to others? Right. Yeah. And I think this can bring joy again to yourself, right? If you maybe should think about how can I make the day, a little bit better for my colleague today? Or help somebody? I think this can be a cycle of positivity. I dunno. Like, yeah. 

[00:43:00] Holly: Yeah, absolutely. I think we realized one of the things that we realized with, with COVID is how, how much we need others and how it’s, you know, it’s not much fun without others. Yeah. Yeah, 

Michaela: exactly. I think so, too. So I hope you all can come back together and then really be nice to each other and care for each other. Yeah. Okay. So Holly, thank you so much for being on my show. Have a wonderful. In them. Yeah. I hope I talk to you soon again. 

[00:43:29] Holly: Yeah. Thank you so much. It was, it was great fun. 

[00:43:32]  Michaela:  Yeah. It was really fun.

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 34: Vulnerability disclosure with Katie Moussouris

In this episode, I talk with Katie Moussouris, founder and CEO of Luta Security.  Luta Security specializes in helping businesses and governments work with hackers and security researchers to better defend themselves from digital attacks. Katie is also an expert when it comes to bug bounty programs and how to successfully prepare organizations to implement a vulnerability disclosure program.

We talk about:

  • vulnerability disclosure,
  • the security challenges faced by military and government organizations,
  • her entrepreneurial path,
  • how to establish yourself as a hacker or security expert,
  • and how to build security in your software development process. 
Continue reading

Episode 33: From intern to CEO with agile testing expert Alex Schladebeck

In this episode, I talk to Alex Schladebeck, a testing expert, and a powerful voice in the tech community. Alex is the CEO of Bredex, a dev shop that offers tailor-made IT solutions but also specializes in quality assurance and testing.

A decade ago, Alex graduated in linguistic and came into tech by accident. So, I obviously have to ask her about her career transition, and testing.

What we talk about:

  • transitioning into tech from a non-traditional background
  • what it takes to get from an intern position to becoming the CEO 
  • which role testing plays at Bredex
  • how mob or ensemble programming is used to facilitate learning
  • how to lead remote software teams
Continue reading

Episode 31: Combatting tech debt in war rooms

In this episode, I talk to Tomasz Łakomy, a senior frontend engineer at OLX Group. Tomasz is fascinated about teaching everything he knows and has over 170 video tutorials.  

We talk about:

  • how they develop, test, and reviews software at OLX group,  
  • what war rooms are and how they help to combat technical debt,
  • how he managed to create over 170 video tutorials about software engineering,
  • why he is AWS certified as a front-end engineer, and
  • how skydiving helped him to be a better software developer.
Continue reading

Episode 29: No mocks allowed – A testing discussion with Kent C. Dodds

In this episode, I talk to Kent C. Dodds, a software engineer, and teacher. Before starting his entrepreneurial journey, Kent has been working for PayPal. He is a major open source contributor and also the creator and maintainer of the widely used open-source testing-library.

Code that he writes is used by millions of people around the world, and he also teaches thousands of engineers how to test their JavaScript systems, and how to work with React.

We talk about:

  • Why you should not mock your software system during testing,
  • how “testing library” helps create more meaningful and maintainable tests,
  • if and how manual testing is still needed to increase your confidence in the software system.
Continue reading

Episode 28: How design systems help create an inclusive user experience at Github

In this episode, I talk to Diana Mounter, the Director of Design Infrastructure at GitHub. Diana traveled the world and lived in many different countries – even continents. She started as a print designer and spent some time in government before she got into web and design. Now, she leads the design systems at GitHub.

We talk about:

  • what design systems are and why we need them,
  • how GitHub deals with legacy code and refactoring.
  • how the designer role interplays with other roles at GitHub,
  • how and why designers do code reviews,
  • and how GitHub strives for inclusive designs that make everyone feel like an expert.
Continue reading