Transcript:
Joe Krebs 0:10
Agile FM Radio for the Agile community. www.agile.fm.
Welcome to another episode of Agile FM. Today I have Claire Sudbury with me. She's the queen of questions at Made Tech, we're going to go through what that actually means she is out of Manchester, UK. She is a fellow podcaster. Also in the Agile space with a podcast that's called Making Tech Better. That title implies that we can be better, which is something we want to explore in this podcast, I'm going to share all the contact details LinkedIn, Twitter, how you can get in touch with Clare on the show page. But before we go right into the topic of Agile software development, I think that's where you had to find an umbrella term. That's for today. Welcome to the podcast.
Clare Sudbery 1:00
Thank you. Hello.
Joe Krebs 1:04
Thanks for joining me here to this to this podcast. And I have to confess, for a few episodes, we've been talking cultural topics, leadership topics, sometimes really scrum related topics, etc. This is very different because we're gonna explore the tech space a little bit. You're the host of a podcast that explores these techniques, that leads to better software, better technology, like better products using technology, we want to explore some of those now I have to also confess that my software engineering background a few years ago, I developed it in smalltalk and Java, etc. But it's been a while. So I'm super curious to see what's going on in the software development, what kind of trends we're gonna see, especially around XP. So what is the queen of question do?
Clare Sudbery 1:54
That's a very good question. Well, so I mean, the most obvious place in which I am the queen of questions is the fact that I host a podcast. So I spend a lot of time asking my guests questions. But I also am just a person who asks a lot of questions. I've always been a person who asks a lot of questions. Whenever I'm a pupil in a classroom, I'm always that annoying person who has their hand hand up and is asking yet more questions of the teacher when everybody else is wants to go home. I always want to know more. I always want to understand things in detail. So it applies when I'm podcasting. But it also applies when I'm in technical leadership. So when I'm leading teams, as software engineers, I'm asking how could we do things differently? How can we do things better? Are we doing the right things? Are we even asking the right questions? So I'm asking questions about questions.
Joe Krebs 2:46
Meta questions, wonderful.
Clare Sudbery 2:50
But I'm also asking our clients, so we are a consultancy, I work for made tech and I'm asking our clients, you know, what are the problems that you really need to solve, which aren't necessarily always have questions, the problems that they think they need to solve? So it's also about knowing what are the right questions to ask to really get to the nub of the problem, and therefore make sure that we're on the right path to an effective solution.
Joe Krebs 3:15
Yeah, this is awesome. I mean, the maybe today, this just makes you a little bit more uncomfortable, because I have some questions for you. But I noticed that in your profile, and one thing really stood out, and it was the title of a professional software developer, you labeled yourself in one of your professions, right. And it's interesting, the word professional, obviously, right software development as a lot of software, software development going on. But the word professional, there's, there's a lot in there, right? When you get in front of a software developer.
Clare Sudbery 3:48
Now, that was actually the company that I worked for, had simply decided that that's what they were going to call software developers. And I do actually remember thinking that surely that word is redundant, because if we're being paid for it, then we are professionals. And so that was one of those were really it was outside of my control. There was simply a decision that this is what we are going to call our software developers. We're going to call them professional software developers. But it is it's a good question. Because funnily enough, I was talking to one of our podcast guests the other day, Charlene Hunter, about teaching software engineers, which is something that I also get involved in, I helped to train up our junior developers at made tech. And she was saying that in our training program, we are making a distinction between coders and professional software developers. So what we do is we take people we expect them to have learned to do some coding. And then what we say is, being able to code is not necessarily the same thing as being a professional software developer. So if you can write code, that's fantastic. That's a really good start. But just because you can write code doesn't necessarily mean that you can collaborate as part of a team to create a software product with users in mind that is developed for an organization that has a particular direction that it's trying to move in. And that has its own definition of where the value lies. So writing code in and of itself is not necessarily enough to be able to develop a significant software product that has users and will continue to develop and improve throughout its life. So I think that there is a distinction, in fact, being a professional software developer is more than just writing code.
Joe Krebs 5:42
Yeah, I think it's also when I just think about like being professional about writing code, it's it also means to possibly say no to a release, if you don't feel like the quality is there, right or being professional about the quality, you're producing the quality you're observing possibly on the team being pushed into possibly where which you feel uncomfortable space and pushing back.
Clare Sudbery 6:07
But there's so much in there. I mean, I've already my brains going off in five different directions. But there is the there is the pushing back element is something that software developers find extremely difficult. And I think to be honest, most people would, because it implies a certain level of conflict. And what's something that's really common that we see in software development is that we have stakeholders and business owners who have deadlines that they're trying to meet, and they become, and everybody becomes extremely focused on the deadline, and forget about quality because they're in such a panic to reach this deadline. Sometimes those deadlines are genuinely important. Like, you know, a thing, like the obvious trivial example is if you're working with a concert venue, and you're working to sell tickets to an event, well, once the event is gone, doesn't matter what you do, it's useless. So you that's a very hard deadline. And in fact, in the way that our podcast works is we deliver episodes every Tuesday morning at five o'clock, not every Tuesday morning, every other Tuesday morning at five o'clock once a fortnight, and where we are very strict about that. So that means that we have hard deadlines once a fortnight. But most of the deadlines that people are given are actually quite arbitrary, have been decided, based on quite odd criteria. When you look into it, actually, nobody's going to die. If you don't meet this deadline. People become absolutely fixated on the deadline. And often often the sprint structure of Scrum, software development and other forms of agile that focus on a sprint that can also become an arbitrary deadline. That means that people are are putting quality to one side simply because they feel like they're in a rush to meet this deadline.. It's incredibly difficult for people to say, No, slow down, stop, wait a minute, what about the quality, and particularly for software engineers to say, You know what this job that we do requires a lot of brainpower, it requires a lot of thought, it requires a lot of conversation. And if we feel that we have to be sitting at our keyboards tapping away writing code every minute of the day, and any time not spent, coding is wasted. Then actually, quality suffers. And not just quality, but our health, our mental health. But still people find it so hard to say, Whoa, you know what I would like time to think I'd like time to pause, I'd like to step away from my desk and go for a walk or have a meeting with a colleague have a conversation to a diagram. People find it very hard to say that in the face of the pressure to meet the deadline and to look productive. So yes, I think pushing back is is important, but also surprisingly difficult. And I think sometimes people say well, why didn't you push back without taking account of the fact that that is hard?
Joe Krebs 9:22
Oh, it's definitely hard. Right? Just like while you were talking about the deadlines is like, I totally agree with you these deadlines. Sometimes they come out and you when you asked him questions about how did this deadline, this date, have something come up? It's like, hardly anybody knows how that date actually emerged. But that's the date. Sometimes I have seen dates that would fall on a Sunday. And I was like, what because it was the first of December, let's say, Sunday, let's say are you really planning on releasing on Sunday? No, no, no, of course not. Right. So and but people do think about these deadlines, obviously. Why? Because there's obviously a business reason. Hopefully associated with that, but what I want to explore with you a little bit is the other party just said, and that is the, besides the deadlines to pause to think. And that's something I want to run by you because I might be out of touch at this point. But I'm gonna run this by you. When I worked on software development projects myself. There was a high degree of visualization collaboration among team members, I would say and maybe that is the statement that is either right or wrong, it was we hear from you about whiteboarding electronically or in person, just the idea of collaborating together to for six people solving common, like a complex problem of some sort. I'm not saying that collaborating constantly. I'm not saying there will be lots of modeling or anything behind this, but I'm just saying like, I feel like lately, what I'm observing when I work with teams is more like the coding aspect and more chatter on Slack or, and things like that, less more like face to face to face. What's your take on that?
Clare Sudbery 11:09
Well, first of all, I don't feel like really anybody can necessarily authoritatively make blanket statements about what's happening in the industry, because, you know, I only have my own experience to go on. And that experience, it will be broader than some because I've been working in consultancy for the last five years. So that means that I have been able to see across companies and across teams, so I haven't just been in one context for the last five years. But I wouldn't say that I have observed that as a trend. What I would say is that it is difficult, always always has been. And I suspect it always will be to persuade people that the best way to work is highly collaborative. So the best way to work, I would agree with what you were implying the best way to work is for people to spend time whiteboarding for people to spend time having those conversations for people to take a tech take a step back from the keyboard, and actually stop and talk and think about what they're doing. I think that it has also been particularly difficult in the last 18 months because of the pandemic and lockdown. So a lot of my colleagues have said how much they miss actual physical whiteboards. So now if we want to draw a diagram or have a in inverted commas whiteboarding session, we have to use tools like Miro, which are very good tools. But when you're not physically standing up and moving around and physically moving, post it around, I do think it you lose something, I think there's actually you know, there's something about the physical interaction with things that can really make a difference about how it interacts with your brain. So I do think that lock down has maybe exacerbated a tendency for software developers to want to work individually. And to just want to get stuck into looking at the code and not want to be bothered with having to talk to other people about it. I think that there is, I think we've been encouraged to categorize ourselves as developers of being a particular type of person that likes to have a one to one relationship with our computers and not be bothered to have to talk to other human beings. I particularly when I first started in my career, 25 years ago, I thought that that was the appeal for me, I'll be completely honest, I wanted to talk to a computer and not have to talk to people. I didn't like it when people came and stood at my elbow and tried to have real conversations with me, I preferred it if we could converse via email or, you know, the equivalent of slack. And that was when I wasn't working from home. So it was very easy to have physical conversations with people. And yet, I still prefered to have virtual conversations. And I had to be persuaded and I have very much been persuaded that now I realize now I prefer to I want you know, My ideal is to be in an office with my colleagues, to be able to use whiteboards to have a lot of collaboration, a lot of communication, a lot of time away from the keyboard. But I that was a journey that I went on. And that's a journey that I'm constantly bringing other people on as a consultant. And I think that there are lots of pressures that work against that one of them we've already talked about, which is the deadline. It's the idea that everybody must be productive. It's the idea. It's kind of treating the human beings as though they were components in a factory, that if they're not actually don't actually have their fingers on the keyboards and are not writing code, then they're not productive to this idea that you can measure productivity by lines of code, which is wrong, but it's beguiling. You know, it's you can see why People might think it might be true. And anything that stands in the way of that feels as though it's slowing you down. So it feels as though oh no, if I have to go and have a conversation with somebody I have, I have to go in a meeting, then all of those people in that meeting aren't producing code. So time is being lost. And, and that's, that is a conversation that as a consultant, I have to have over and over again, and I'm not sure that that will ever change. I think that in my ideal would be that everybody realizes that the gold standard is first of all, for for software engineers to be ideally pairing a high proportion of the time or even mobbing (mob programming) for people to regularly stop draw diagrams have conversations for people to give themselves time to think without feeling they have like they have to ask for permission for it to become standard for people to go for walks and give just give their brains time to think for people to know about the for instance, the fact that there's tons of research that suggests that our brains process things in the background, when we're not consciously thinking about them that actually we benefit from having time away from just banging our head against whatever problem it is we're trying to solve. But I don't, I don't know if we'll ever get to a point where that is just the accepted norm. I wonder whether and I have no I don't know anything about your career. But I wonder whether you fit the reason you feel like there's been a change is because this this kind of golden period that you had in the past was maybe just that you were working in an environment where people bought it and had managed to learn those lessons.
Joe Krebs 16:40
Better? Oh, yeah. It was just more like a more visual thing. Maybe it was more common to go to a whiteboard, maybe it was so different at that time to go to a whiteboard, maybe it was more acceptable to say, Hey, I'm gonna go with my colleague XYZ on a long walk. And while we talk, we talk about a complex problem. And we come back with fresh new ideas. Why? Because I think that is, that's just something I took. But that could be just me by walking, and you're definitely closer to the, to the source here. In this case, where I want to talk a little bit about the social aspects of software development to like the pairing and everything. How would you get people to towards more pairing? How do you encourage people to do more pairing who feel like like you what you just said about yourself? Right? When I would be in dialogue with the machine, I'd be the person.
Clare Sudbery 17:33
Yeah, yeah. And the way that I learned which I think is the best way is, is by having an experience of it. Because when I first joined the industry, I mean, I've been in the industry now for 21 years, but there was a gap in the middle of four years. So it's about 25 years since I first became a software engineer. And about 12 years in so about 15 years ago, my math is falling apart a bit at this point. But a while ago, I first heard of pair programming, and somebody mentioned it, and I said, Oh, what's that? And they said, Oh, it's when two people sit together. So software engineers sit together and write the code together all day, every day. And I said, that sounds ridiculous. And it sounds like hell. Horrible. Why would I want to be shackled to another software engineer all day, every day? What if I want the loo? What if I want to make a cup of tea? What if I, what if I feel like you know, and this is something that I never didn't necessarily feel confident to say out loud to anything, anybody other than my friends. But what if I feel like surfing the internet for a while and you know, I want a bit of downtime. And of course, actually, that's what everybody does. And, and I also thought that I have a very individual relationship with with the code, and somebody else would just get in the way of that. And, and then I tried it. And the way that I tried it was by being involved in XP workshops. So this was on my own time, I think the very first time I did any pairing was a day long workshop organized by XP, Manchester, which is where I'm based. And we split into pairs for short sessions. So I think it was something like four hour long sessions. And in each one, we wrote some code and then we threw it away. And then we joined another pair and started again and then at the end, we throw it away again. So those two things, they were very radical to me the idea that we might throw our code away, and also the idea that we might be working in pairs and I was really quite scared because I'm you know, I'm a little bit shy and I was convinced that everybody they knew more than me that they were all much more experienced. The other thing that the other thing that I was introduced to as part of this, the very same workshop was test driven development, which I was also new to, whereas a lot of these people had done it but before, and I just thought, Well, I'm not going to know what's going on, I'm going to expose my ignorance, I'm going to feel inadequate. And I'm going to slow down my pair every time because they're going to know what they're doing. And I'm not. And first of all, I discovered that they were very nice. They didn't mind if I slowed things down, they didn't mind that I asked the millions of questions that I always ask because I always have been a big asker of questions, they were happy to answer those questions. And that actually, a lot of the questions that I was asking, made them think as well as we use to them. And also, I discovered, there were actually things that I knew that they didn't know, which without the pairing I wouldn't have ever discovered. So I would have continued believing that I'm the only person in the world that Google's every other thing. And I'm the only person that forgets the names of things all the time, and I have to keep looking stuff up. And I don't carry an encyclopedia around in my brain, it's very easy to believe that everybody else knows exactly what they're doing. And you're the only one that doesn't, until you pair you don't realize, oh, actually, it's not just you, it's everybody. And also you realize that you there's a lot more value in what you know, than you realize, as soon as you're working with somebody else, and are able to teach them something that you know, then you start to see the value of your own knowledge. And then the other thing that I realized was that I absolutely have a tendency to disappear down rabbit holes. And again, that I'm not the only one. And when you're used to working alone, so I had been working in environments where not only did we not pair, but we didn't have daily stand up's, it was quite normal for you to be given a piece of work and then disappear for several weeks, there might be regular meetings, but they certainly weren't daily catch up's. And you were pretty much left to your own devices, which is fine until you get stuck. And if you don't feel confident to admit that you're stuck, then you get more stuck. And the more stuck you get, the harder it gets to ask for help. And the harder it gets to admit that you haven't actually made progress for a significant amount of time because you're stuck. And it's horrible, horrible, this awful kind of hole that you disappear into. And so that's that's one way in which it's very helpful to have somebody sitting right next to you who can instantly help you. But the other thing is that I mentioned before, which is going down rabbit holes, which is a slightly different thing. That's where you think you've worked out which direction you want to go in, and you've decided on a particular direction. And you actually might start to realize after a while, I'm not sure this is getting me anywhere. But I've started so I feel like I need to finish. It's kind of it's the sunk cost fallacy in miniature. When there's somebody sitting next to you, they're gonna say, What are you doing right now? Why are you doing that? You know, are we and you can say to each other, are we actually going in the right direction right now? Are we doing the right thing? Do we need to pause? And I mean, it's not a panacea, because it is entirely possible. And I'm sure many people who have paired will have had this experience, it's possible for a pair to disappear down a rabbit hole, you can both persuade each other that you're going in the right direction, they'll disappear down a rabbit hole, but it's less likely. And there are more checks and balances. And then yeah, I mean, I could go on for hours about all the benefits of pairing but but the other obvious one is that you share knowledge. So the other thing that was very much a feature of the early part of my career is that there would be people within the company within the team, who knew all the stuff, who'd been working on the product for a long time, who had deep domain knowledge and deep tech stack knowledge of the stack that we were working with. And we're really the only people who could solve a plethora of problems because they were the only people that have that deep knowledge. And that become this heart became this horrible self fulfilling prophecy that we can't ask that man over there for help, because he's too busy doing a really crucial job that nobody else can do. And he doesn't have time to share his deep knowledge with anybody else because he's too busy fighting all the fires that only he can fight. I just realized that I said he because at the time, I was the only female software developer on the team. But of course, it doesn't have to be a he. But, but you know that business of not being able to share knowledge goes away when you are regularly in the habit of pairing that there are nearly always two people who've had their eyes on any one piece of code. So there isn't only one person who knows how it works,
Joe Krebs 24:54
as opposed to knowledge sharing where, people have purpose when they come to work. They want to learn they have a career path too, it's not like, they feel like, Hey, I learned something. Today I went to work, I learned something from a colleague, I got a new, you know, it could be a trick with a tool, it could be learning something about how to apply patterns or something like that could be anything that somebody will take home with them, it's this, this was worth worth spending at work and appearing, definitely encourages there.
Clare Sudbery 25:26
And there's that lovely moment where you use a particular keyboard shortcut, or you use a feature of an IDE that your pair doesn't know about. They say, well hang on a minute. Oh, is that? That is cool. And you know, the amount that you learn as a result is fantastic. And I've been reminded of this recently with the podcast, in fact, because when we started making the podcast, it was very much my baby, and I was doing most of the work. And that became unrealistic. So I needed to teach colleagues how to, you know, do all the various different aspects of podcast production. And it was frustrating at first, because I had developed a rhythm and I had actually developed a much deeper knowledge than I didn't realize they had about how to produce a podcast and all of the various different editing and production tasks. And you know, how to record an interview, how to interview a guest how to lots and lots of different things. And I started to share that knowledge so that so that I wasn't the only person who could do it, it was just never a good position to be in, it's if you think that that's a good way of getting value as an individual it isn't. It's a millstone around your neck, you should never want to be the only person who knows how to do something. And so I started to teach my colleagues and at first, it was frustrating, because there were things that I could do really quickly. And I thought, I'll just tell them how to do it, and then they'll be able to do it too. And I would tell them, and first of all, they wouldn't get it instantly, because actually, I was given them really a lot of information. So they would come back to me with questions like hang on, I didn't quite get this bit, and what about this bit, and then second of all, the first time that they did it, they wouldn't do it as quickly as when I did it, not because there's anything special about me, but just because I had been doing it for longer. And that's that was frustrating, because the reason I was trying to hand off these tasks was to free my own time, and to just, you know, make the whole process more efficient. And initially, it didn't, it made it less efficient, because the you know, I was having to spend time teaching people, and they weren't yet be able to do it as fast as I could. But that, and it's very common that at that point people give up, because that happens all the time in software teams, people, you know, with the idea of the bus factor, I don't know if you if you heard that phrase, the bus factor, that somebody has a high bus factor, if if they are if they get run over by a bus, it will have a high impact on the teams. That gives them a high bus factor. And you want to reduce the bus factor. But in order to reduce the bus factor, you have to share knowledge. And in order to ship to share knowledge, you have to teach other people and you go through that whole process I've just described. And often people find that frustrating. And they give up. So they say, Oh, I tried to teach it to somebody else. But it was no good. They did. They didn't they didn't understand what I was saying. And it was too slow and too frustrating. So I've just decided I'm just going to keep holding all the knowledge to myself, not because I want to, but because anything else just feels too hard. And and that's very short termist. But but we know brains naturally are quite short term. So you have to, you have to encourage each other to take a long term view. But when you do you say okay, yes, this is short term pain for long term gain, that when I get all these people up to speed, I will be able to walk away at any moment and know that other people can pick up the slack. And that will in the long term be much more effective.
Joe Krebs 29:01
Yeah. Clare. All what you just said I want to link to another topic. Okay. Yeah, because I think there's there's something in there. Obviously, the the social aspects of collaboration, building a product together, sharing, not being in silos. I'm going to make another general statement. And that general statement is about there's a lot of people that refer to agile as iterative development, let's say right? So there's a there's iterative development going on. And they're working in short cycles, etc, etc. But what's also important is that it's iterative, incremental. So the increment that to just to stick to a term out of the scrum world, but you know, is a piece which we want to build at the end at least once at the end of the sprint. And that is that is a product that is potentially releasable. Yes, this is where the general statement comes in. I've seen teams struggle trouble building increments sprint by sprint by sprint, not even multiple increments per sprint just like one. But it's and it's obviously, I don't know if that is it is related to let's say this the silo thinking that learning that pairing all of those things you just mentioned, asking for help, etc. But sometimes he you know, we see still answers today when I work with lesser experienced teams. They're like, well, we got the software down but not tested, right? Or we got we got a piece of software here but not integrated. So why is it that it's 2021 Ron Jeffries wrote this XP book many, many years ago? Why do we still struggle? What's what's so what do you think is behind that in software engineering teams? I mean, it's the push back, is it possible, the deadline? Is this the knowledge? But what do you see when working with him? So maybe I'm totally wrong, maybe on your site teams are producing increment by increment on a daily basis.
Clare Sudbery 31:01
No, it's yet another thing that isn't easy, and does take effort and continued effort. And I think maybe what generally, what we're, what we're talking about here is the fact that people want there to be a manual, that you teach me how to do software development, I will learn how to do software development, and then I'll know how to do software development tick done. And it isn't that simple. It's it's continuous, you have to keep fighting these battles, keep having these conversations keep showing the value of doing things in certain ways. And the increment is a very important concept. So I tend to I like the phrase vertical slice. So the idea that what you want to do is deliver a vertical slice of your product from end to end. And that your definition of Done should be that it is in front of your users. So as you said, it's been tested, it's been integrated, it's been deployed, people are using it. And in order to have that mindset, you first of all have to have people who are who to skills cross a number of disciplines. So they have to understand how to make sure that testing is done, they have to know something about deployment. And that can be frustrating to people, I think, sometimes people, they want to be in a comfort zone. So people do tend to say, this is the thing that I like to do, this is the thing that I'm good at. So I'm going to stick to this thing. And then when I've done my bit, I'm just going to hand it off to somebody else and forget about it so that I can go back to doing the thing that I really enjoy doing. And in order to persuade people that it is worth seeing it through and caring about it all the way until it's in front of the users, you have to sometimes take them outside of their comfort zones. So that's one thing. Another thing is that it can be very tempting when you're looking for efficiencies, to think well, okay, these silos make sense, because you think of it like a production line, you know, my job is just to do this little bit of the process. And then I'm going to chuck it over the wall to the next person to do their little bit of a process. And that feels efficient. Because I can keep doing my little bits over and over again, I'm really quick at it, I know what I'm doing. But the problem is that unless something has gone all the way to production, you don't know whether you've built the right thing. You don't know if it works, you don't know whether it's going to come back again, with bugs or simply being told it's not fit for purpose. So it might not have bugs, but it might not be what our users actually wanted. Because the ability to have a dialogue with users and stakeholders and to really understand what the best thing is for us to create. That's highly complex, lots of things can happen. Even if you've got a really good relationship with your users, they can tell you exactly what they want. And then you deliver it and they realize that they were wrong. They didn't want what what they thought they wanted, or it doesn't actually do what they need it to do. There were things they hadn't thought of, or there are new things that have come into play. So getting something in front of your users quickly, so that when you discover that there are things wrong with it, because there always will no matter how effective your process there are ways of reducing the likelihood of that. But there will always be things that need to change. The quicker you can get things in front of the user, the quicker you can fix those problems. And the more likely it is you can remember how to fix it because when you made it in the first place, it was recently enough that you can still remember the detail. So that's that's why we want to deliver in vertical slices and why we want to deliver in increments but persuading people of that is a bit chicken and egg because until you have a very effective process that allows you to deliver vertical slices end to end. You won't see the benefit of it. and also you do have to persuade people that they're going to have to spend some time outside of their comfort zone that they're going to have to care about things that they don't immediately find interesting. You know, and also, you're gonna have to ask people to spend time with people that they might not feel comfortable about. So not everybody is delighted by the idea of being in contact with their users. Some people see this as being stressful people who are who are, you know, antagonistic and cause problems. And, and that's not because users are not necessarily like that. But it's because as soon as we start to divide ourselves, and it becomes very easy to get defensive. And as soon as two parties feel defensive, then each party feels as though they're, they're being attacked. And it's incredibly easy for groups of people to, to find themselves in that situation. And to start to see the I mean, there's, there's tons of psychology about it, the idea of the out group and the group. But as soon as you see a group of people as being other from yourself, then they they become net, potentially a source of stress. And it's, it's not simple to get development teams into a situation where they see their users as their collaborators, and they see their stakeholders as their collaborators. And they see that they can, they can take responsibility for and take an interest in, in all aspects of the software development lifecycle. It's not easy, and there are reasons why people will tend to gravitate into silos, and why people think that looks efficient. So it's a constant conversation, you have to prove it. And in order to prove it, you have to have certain things in place. So for instance, I'm a big fan of trunk based development, which is where every commit in the code goes to the main branch of your code, and then gets deployed as quickly as possible. Now, this is controversial, not everybody agrees with me. But there are a significant number of people who do that as soon as you create a feature branch, then you are diverging your codebase. And inevitably, at some point, you're going to have to merge that code. And by doing that, you're slowing down the speed at which your code can get in front of your users, you're not just slowing it down in time, you're also increasing the amount of complexity and therefore increasing the likelihood that something will go wrong, increasing the risk. So it's more likely that bugs will happen that merge conflicts will happen. And then you'll have to spend time fixing those bugs and fixing those merge conflicts instead of getting that code in front of your users. But in order to be able to get rid of branches, you have to work in a very specific way. You can't just write code in the way that you're used to, you have to think of every commit as potentially being something that will be deployed. And for a lot of people that sounds crazy, because they're used to pulling everything apart, and then putting it back together again. And and that you can't commit, you can't deploy every commit, that would sound crazy. To some people, it is possible, but it requires a different way of working, it's a skill that has to be learned. And then in order to learn it, you have to persuade people that it's worth learning. And it's it again, the reason it's chicken and egg is the reason you want people to learn, it's so that they can see the value of smart fast feedback loops, small vertical slices, getting things in front of the user as quickly as possible. But you can't demonstrate that until they have enough skill to be able to do that. In you know, and you have to persuade them why they would want to learn those skills in the first place by demonstrating it, but you can't demonstrate it if they can't do it. So, you know, it's it's long. Yeah, it's when you're seeing it work. It seems obvious. And it's frustrating if you can't persuade people. But if you haven't seen it work, it sounds painful, difficult and slow. So it's it's not easy.
Joe Krebs 38:59
It's not easy, but it has a focus on the increment, right? Which is so so important, because that is that is value. And I can only agree with you all the teams that are producing increments. There is a, you know, it's definitely boosts morale on a team because it means that we have value produce, right. So in these short cycles, so but it is so hard to produce, because sometimes it's what you just mentioned, or the imbalance on of skills on a team that we have too many engineers and just not enough QA. And that is, you know, we might have a lot of code, but it's not QA and if you're breaking down the silos, and if you're working as a team, and you're learning and sharing and get out of your comfort zone. Yeah, that increment might be achievable. By the by the end of the sprint. So there's a lot in there. But you know, I often see that as a as a key element of development. So towards the end of our conversation you and I do have to say came back to and I cannot just say Ron Jeffries with XP books as well, obviously, can Beck's book there. So I've just shout that out. That's also an important book. In this thing, how do you feel about I just to the end of our conversation here about throwaway software, I see like software being like produced in shorter cycles. You know, the business world ideas being built on more and more software than it has been ever cars, everything includes software at this point, everything. So how do you feel about throwaway software, like instead of, you know, refactoring or solid software engineering practices to build code, and if needed, we're going to throw out the system and building a system because the business will change so fast about these trends?
Clare Sudbery 40:40
Yeah, that was one of the things that came into my head when you talked Right, right back at the beginning, about quality about making sure that you have quality in your software where because actually, there are times, when you might say, in order to move quickly, we aren't going to dot every I and cross every T. Personally, I find that painful and difficult. Because I want to always produce a really good quality software piece of a really good quality product. But actually, yes, there are times and you what you have to do is you have to ask those questions, you have to say, is this something that is going to have longevity, and is this something that is going to be a crucial component that is going to be shared with other parts of our system, you know, so for instance, and it's not an easy thing to be able to detect. So for instance, software engineers are notoriously bad at knowing which bits of their code they should optimize. So you know, you will frequently see software engineers spending hours tweaking a piece of code to be the most efficient piece of code everywhere ever and, and not use too much memory and not not be too slow. And then once the whole thing is completed, you do some you run some performance tests, and you discovered that piece of code that they spent hours and hours and hours tweaking and optimizing hardly ever is hardly ever hit doesn't actually matter, it could have been 10 times as slow and it wouldn't matter because it's never called. Whereas the code that is called repeatedly and is slowing your product down is the one that you didn't realize, because you know, so premature optimization is something that you have to be aware of that. And you also have to know how to move fast. So for instance, you don't necessarily want to build a highly complex pipeline. At the beginning of your product project, you do want a pipeline, I would definitely say deploy as early as possible. I'm a big fan of The Walking skeleton, but don't necessarily make it all singing, all dancing, because what you might do is build in optimizations that you don't need. So wait until you're in production and then say, Okay, now what do we need to tweak? Where does the quality need to be? Which bits can we throw away? And it's not? I don't think there's an easy answer. So I think yes, there will, there will sometimes be things that you throw away, it's hard to know in advance which things they will be, there are definitely practices that you can use that will that will make it more likely that you can enhance and optimize your code. And I would definitely say building tests from the beginning, because they are almost almost always useful. And always be thinking about refactoring. But sometimes you know what that thing there might not need refactoring. It might be that nobody ever uses it. So yeah. And it might be that this thing here that you're building can be thrown away. And having that mindset that this is something that could be thrown away, is actually also very useful. The idea of building something and then throwing it away. And then building something else, which I mentioned a while ago, is something is a technique that's used in code cutters and in workshops. If you think of it as being disposable, then you then you can let go of it. And you can say, You know what, I'm going to build it throw away and then build another one. The problem is that if you say, Oh, it doesn't matter, because it's going to be thrown away. That's nearly always the thing that ends up being the absolute core. And in 20 years time, people are cursing your very existence. horrible thing.
Joe Krebs 44:27
You want to really make sure it's will be the intended to throw away otherwise he's outlast you.
Clare Sudbery 44:33
But it is important to recognize that that possibility and to always and this is why the increment is so important, right? This is why thinking small is really, really important. Let's do something tiny as a proof of concept. Let's not let's not design a giant system and try and build it. Let's design a tiny little example of whatever we believe is going to work and let's treat it as an experiment. That doesn't mean that we don't do it to a high standard. But if it's small, then everything is quicker. Everything is lower risk, you know, and you know, baking in quality is a lot quicker and easier when you're doing it to something small. And then you can throw it away when you discover that actually, it doesn't do what you thought it was going to do. You can have hypotheses, you can view it as an experiment. And that speeds you up.
Joe Krebs 45:28
That was awesome, Clare. Good conversation. I know this was a little techie or today for the Agile FM listeners, it was a lot of use of the word software. If you have listened to this podcast and you're not in the software development space, you can replace the word software with probably any other word. It would still make sense, I guess. And, but this was a little bit more software related software development, projects and features, etc. Great insights. I think we covered a lot of ground here, but maybe maybe we start small and maybe you come back one day to Agile FM and more topics and add to it.
Clare Sudbery 46:10
Fantastic. That would be fantastic. I'd love to Yes.
Joe Krebs 46:14
Thank you so much.
Clare Sudbery 46:16
Thank you for having me.
Joe Krebs 46:18
Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.