[Intro Music]
Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast bringing you content from all over the world on how to improve your software delivery. My name is Clare Sudbery, my pronouns are she and her and I am a lead engineer at Made Tech.
On the 13th of October 2021, I spoke to Emily Bache about refactoring, which is a process engineers use to improve existing code. I first came across Emily when I was running a refactoring workshop, and I needed good examples for the participants. I had Emily’s GitHub repro recommended to me, where I found the Gilded Rose Kata and tons of other examples, all designed to help people improve their refactoring skills.
Emily specialises in helping engineers to hone their skills across software development. She really knows her stuff, so I was very excited to talk to her.
Clare: Hello Emily.
Emily: Hello.
Clare: It’s so lovely to have you here. I’m going to leap straight in. Who in this industry are you inspired by?
Emily: I wanted to name Kent Beck. I read his book on extreme programming in 2000 and loved it. That has been a huge influence on me, so I’ve got to have Kent on my list. I was so pleased when he agreed to write the forward to my recently published book.
Maybe in the same kind of theme, Martin Fowler, Geepaw Hill, these pioneers in the extreme programming world. Then more recently Llewellyn Falco has been a great inspiration to me and the continuous delivery crowd, like Jez Humble and Dave Farley. These are the people who inspire me.
Clare: Fantastic, great names. What we’re going to be talking about today is something I know you know a lot about. Generally, we are going to be talking about refactoring. I am going to start with a really simple one. What does the term ‘refactor’ mean to you?
Emily: I like Martin Fowler’s definitions. It’s a verb, it’s a noun, it’s a vocabulary. It’s a bunch of names of operations you can do on code to preserve behaviour and improve structure. It’s a skill. Being able to refactor is a skill that you can learn. Refactoring can be really fun when it’s going well.
Refactoring in a noun. It is a change made to the internal structure of software to make it easier to understand and cheaper to modify, without changing the observable behaviour. That is what Martin Fowler’s refactoring book is about. It’s a catalogue of named refactorings, nouns, all the ones that you can do. Then refactoring as a verb, that is the activity of restructuring software by applying a series of refactorings without changing the observable behaviour.
So it means both. It means the activity of improving the design to make it easier to understand and cheaper to modify, but also, this catalogue of steps that you can do that should be safe and behaviour preserving.
Clare: I really like that about Martin’s definition. When he says, ‘Easier to understand and cheaper to modify’, because I think often people aren’t entirely clear about why they are refactoring. They might just say, ‘I don’t like this bit.’, or ‘We don’t like this bit’, as a team. We think it needs fixing but we’re not necessarily clear about why, and what is the aim. I think sometimes that can lead to problems with people’s approach. One of the things that I’ve seen is people viewing a refactor as a whole project in itself. We are going to rewrite this code and put everything aside and spend several weeks rewriting this code. Do you agree that there are problems with that approach, or can be?
Emily: Yes, absolutely. That’s the symptom of technical debt, where there is a gap between the actual design that you have and the design that you need to have, in order to add the features, you need to add. You need to refactor your design so it will support the new feature. If you have been neglecting this for too long, then it can be a big project. It can take weeks, and you need to have very difficult conversations with your product owner or your business people about what you are actually spending your time on. By definition, if you are refactoring, there is no observable difference. It’s very difficult for managers then to have a meaningful conversation about a refactoring project. Fundamentally, they can’t see what you’re doing. So, you don’t want to get into that situation if you can help it.
Clare: Yes. So, how do you avoid it?
Emily: That’s the small, constant attention to detail, and constant improvements, and an iterative and incremental method, where you are getting that constant feedback about what you are going to build next. Adapting your design of what you’ve got now towards being able to support what you have now realised you are going to build next. It’s constant small adjustments, not this big bang refactoring project that takes weeks or months.
Clare: How granular is that? The reason I ask the question is because people quite often use the paradigm red/green refactor, when they are talking about test driven development. For instance, you write a test, a failing test. You see it fail, then you make it pass, then you refactor. At that point, that should be a really small amount of code. You are already thinking, how can I improve this? How can I make it easier to understand and cheaper to modify?
Do you agree with that? Do you stand by that, that every single test has to have a refactoring stage within its development?
Emily: Well of course, it should be in your mind to think about that. It won’t always happen after every single test. The number of people who are actively doing test driven development is honestly not very large. I think that refactoring is almost a broader skill, or a more frequently employed skill. If you’re building functionality in a code that wasn’t built for testability, you might not have very good tests, but you still need to refactor it.
Clare: Yes. So, refactoring takes place in other contexts as well?
Emily: Yes, not just in test driven development.
Clare: Yes. If you are thinking about making it easier to add new features, for instance, when you are just working on one very small aspect of one very small piece of functionality and just one test, the refactor step at that point might simply be this little bit of code, I’m making this little bit of code easier and cheaper to modify. I’m not necessarily thinking about the next feature, and how this whole bit of code is going to support that, but should I be?
Emily: No. At the level of test driven development, you are thinking about the problem in front of you and the thing you are doing. It’s when you get to the next feature, and you realise that actually, this design doesn’t really support this, that’s when maybe you plan a slightly larger refactoring, but hopefully not catastrophically large.
That’s when it gets really bad, when the design has decayed to the point where you can’t really estimate how long it’s going to take because there is so much to do first before you can get to it.
Clare: That brings two questions to mind, one which we have kind of covered, but which I would still like to dig into a bit more. How do you prevent the code base from getting into that state in the first place? The next one will be, given that it is, because they often are, then what?
Let’s start with the first one. How do you try to avoid getting into that state in the first place?
Emily: I think there are two aspects of it. Firstly, it’s the culture and second, it’s the skill. You can get some very skilled individuals who know how to do refactoring, but if they haven’t managed to spread that as a culture in their organisation, then they can improve code and then the next person comes along and makes it worse again. It needs to be an organisational culture that is supported and understood. And technical leadership around – in this organisation, we keep the code well factored. We invest in the code quality and that’s our normal way of working. Plus, that people get some training and instruction. Software developers don’t spontaneously develop refactoring skills. In my experience, that’s rare. There needs to be some support for training and development.
Clare: Okay. So, if we want people to learn good refactoring skills, we’ve talked about using small steps. We’ve talked about Martin Fowler’s book, where there is a whole catalogue of different refactorings that you can do. Are they the two main components in learning good refactoring skills? How does somebody learn to be good at refactoring?
Emily: It’s a practical skill, just like programming is a practical skill. You need teaching, you need to do practise, you need to do exercises, you need to get feedback on your work. These are all things that can happen just during normal work. There is pair programming, code reviews less so. I think because it’s a practical skill, it’s a much more practical way to learn it, to have somebody sitting with you, showing you and helping you as you work.
Pair programming, ensemble working, then of course self-study, reading books.
Clare: Yes. I’m really interested in the ensemble idea. I’ve just been reading – I haven’t finished yet but I am very much enjoying – your book. I can’t remember the exact title, it’s something like Technical Coaching Using the Samman Method.
Emily: Yeah.
Clare: One of the things you talk about, which I think is a brilliant idea, is visiting teams who are already fully set up, teams who are in production, and helping them to learn not just refactoring skills, but test driven development and all of the skills that come with good software development, by spending time with them as an ensemble. Do you want to talk a bit about that?
Emily: Yes, so this is what I do now, I’m a technical coach. I’ve got refactoring skills and test driven development skills, and I like to try and help people, teams, to learn these skills. I find that if you can get the whole team to work together on a programming task in an ensemble, then I can join that ensemble and prompt them and mentor them to start using more refactoring techniques, write more tests, improve their skills at these things.
That can happen as part of their normal work on their production software. When I coach teams, quite often the first bit is just teaching them these skills of ensemble working. Then once they’ve got the hang of that a bit more, then we can start getting moving a bit more on refactoring skills and stuff.
Clare: In case it’s not clear, some people may have heard the term ‘mob programming’, which is used quite commonly to describe the ensemble. I know that is not a term that you like to use, because of the negative connotations. I’m just mentioning it so that people realise it’s the same thing, that’s what we are talking about.
Emily: Yes, it’s just different names for the same thing. I just think it sounds more like what it is when you say we’re going to work in an ensemble. It’s much more positive.
Clare: Absolutely, I agree. So, in order for people to learn these skills, it’s a practical skill, it’s something that you’re not just going to read in a book, it’s something that you are going to have to practise. Because it is a practical skill, it helps to have a mentor, somebody who is experienced, who can go through all of the subtleties with you. All of the different scenarios.
Emily: Exactly, that’s the way I see it. I like to make this analogy with skiing. I don’t know if you have tried to learn to ski, but that’s also a practical skill. You are standing on these skis going down a slope, and there are different ways to do it. The programmers I work with all know how to programme; they can code. They can ski down a slope. But if they need to learn a new technique for coding, like refactoring or test driven design, it’s like learning a different way of skiing. You wouldn’t expect to just be able to learn to ski by just trying it out by yourself. You’d expect to have skiing lessons and an instructor and trying out beginner slopes and working your way up to a more complicated slope. So, if you’re going to learn refactoring skills, get some lessons, get a teacher, get a mentor. Get someone to ski next to you down the hard slop the first few times and show you how to do it.
Clare: I think one of the key things for me is that refactoring is not trivial. The ability to improve code and make it easier to understand and cheaper to modify is not a simple skill. It’s something that you develop over time and that you get better and better at, and that is worth considering as a first class citizen: as a thing that is worth learning, rather than a thing that just sort of happens.
Emily: Yes. So, one of the questions that you asked earlier that you didn’t come back to yet, was about what to do when you get to this state where your code is in a terrible state.
Clare: You have read my mind. I was about to ask you that question. Yes, Emily, what do you do? Because quite often you will be taking over another piece of code that you didn’t even write yourself, that is in a terrible state.
Emily: Yes, and this is a situation I often find teams in when I come to them. They are struggling, they are not happy. It’s not fun working with code you don’t understand and are afraid to break. It’s difficult. I have this analogy I use with chests of drawers. This piece of code that you have been asked to look after is like this chest of drawers, or a dresser, I think the Americans call it. There is a bunch of stuff in this thing, it has been in your house for years and years and you’re not entirely sure what is in all of the drawers, but it’s essential. You can’t get rid of this piece of furniture because it’s important.
The first thing to do is to pick a drawer and try to pull it out. Take a piece of your system that’s important, that you might need to change, and pull it out. You’ve got to be able to isolate it in a test harness, basically. That step is as far as I can tell, unique for whichever system you are working with. I don’t have a recipe for that. I know that if you’ve got a large piece of code that is difficult, you probably shouldn’t start with all of it. You should slice off a piece, pull out a drawer. How you break those dependencies, that’s a skill in itself. Once you’ve got that and you’ve got it in a test harness and you’ve managed to write one test, then you’re rolling. Then you can suddenly start to add more tests and get coverage over the whole thing, and really pin down the behaviour of that thing.
That’s where I start to use a technique like approval testing. That drawer that I’ve pulled out is much bigger than a unit that I would have in a normal unit test. So, I don’t think the same techniques apply. It’s a different situation, and I would use different tools.
In my experience, approval testing is a really good approach for this. That again might be a challenge. You’ve got to maybe find realistic test data, go to the customer, and find out how they use this thing and what the business rules are. Once you’ve then got enough test coverage that you feel confident, then you can refactor it. Then you can start to improve the design.
Clare: Yes. So, your approval tests are effectively saying these are all of the different ways that I expect this code to behave, all of the different ways that are important. So, all of the edge cases that I know are important and that I want to preserve. Once I’ve been able to define what this code does, and how it behaves already – because I already know that it works – and I have tests that automate that and express that so that I can run the tests and check that it is always behaving in the way that I think it will behave, then when I start changing it, I’ll know if I’ve broken it because the tests will start failing.
Emily: Yes.
Clare: Something I’ve noticed when I’ve done this myself is that quite often in the process of writing the approval test, you will find bugs. Because actually, you are deliberately expressing every edge case. You’ll say what will it do in this scenario and this scenario? How does it behave in these circumstances? Somebody will tell you that in these circumstances it is supposed to do this, and then you write the tests and you’re like, well, actually, you know what…
So I’ve found that you maybe want to start by even noting that the bugs exist, and recognising that these tests are currently failing, but we know they are, and this is what we expect. Or maybe, fix those bugs and then go on to do the refactoring. It depends what state it’s in, and how well you know it.
Emily: Yes. I’m a bit uncomfortable about this because the thing is, if the thing is in production, people are using it and relying on it. If you find something that you think is a bug, somebody might well be relying on that behaviour. It’s very dangerous actually to just think, it’s a bug, I’ll fix it. I think you have to be quite careful.
Clare: So, in a sense, what you’re doing is you’re simply using those tests to observe the existing behaviour and preserve and document. To say this is how this thing behaves in all of these different scenarios. We are going to document that, we’re going to automate it, we’re going to find a way of checking that it continues to behave in that way, so when we change it, we know that we haven’t changed it.
Emily: Exactly. That’s the essence of a regression test. That’s what you create with approval testing techniques. You’ll notice if the behaviour changes. You have to make an explicit choice whether to approve any changes that you do insert. You can have a conversation about those changes with business people who actually understand whether that is a bug, and who will be impacted if you change it.
Clare: Yes. I really enjoy this whole process. For me, refactoring is like tidying up, and tidying up can be really satisfying. I was away last week, and I was doing some recording. I took a lot of recording equipment with me, which means that I had a lot of cables, all in a box, all tangled up. There is a bit of an analogy there for me, that you’ve got some cables and you’re not even sure how many, but you are trying to isolate them from one another. That feels analogous to me to the business of finding the dependencies and isolating one chunk of thing. Because once you’ve isolated one cable, then you can start to untangle that one cable, without having to worry about all of the other cables that are also caught up inside it.
For me, the business of first of all isolating a component which as you say, is different every time and is also not always trivial, then the business of writing the test harness, both of those things are highly satisfying to me. You are making things tidy, and you are making things observable and definable. I imagine that depending on what you are working with, both of those steps can take time. You do want to do both of those steps before you move onto the next bit.
Emily: Yes. Before you start refactoring too much. You will have to make some changes to isolate that thing, but you’re going to want to do that in as safe a way as possible, with perhaps manual testing or something else as back up, yes. Once you’ve got it in your test harness and you’ve pulled out the drawer, then you can start covering it in tests, sorting it out, pulling out all the socks. Finding out what’s in there, getting it all covered with tests and then you can refactor it and start to put everything back neatly, in the way that’s going to make it really easy to add the new features that you need to add.
Clare: Yes. I guess there is a bit of a catch 22 at the beginning of the process, that in order to isolate it and test it, you might have to make changes?
Emily: Yes.
Clare: What techniques can you use at that point, to stay as safe as possible?
Emily: Exactly what change you are going to make depends so much on what system it is. You’ve just got to be really cautious, generally, and use your knowledge of the language. If you’ve got a compiler you can lean on, to a certain extent your normal manual testing and release processes that you already have in place. Which might be very slow and unsatisfactory, but hopefully you can make some progress.
Clare: Yes. I guess also, again, small steps. So, just change the smallest possible thing that you can and then check if things are still working, so you can easily isolate where problems were introduced if they were introduced.
Emily: Yes. And if you have access to anyone who actually knows the code, anyone who actually wrote it, that can really help you. They might be able to point you in the right direction, and show you places where you can break dependencies in a safe way. That’s not always possible. Quite often you are working with code where everyone who built it has left long ago.
[Music sting]
Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am quite choosy about who I will work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open source employee handbook on GitHub, which I love. We have unlimited annual leave. But what I love most about Made Tech is the people. They’ve got such passion for making a difference and they really care for each other. Our Twitter handle is @madetech. That’s M A D E T E C H. We have free books available on our website at madetech.com/resources/books. We are currently recruiting in London, Bristol, South Wales, and the North of England via our Manchester office. If you go to madetech.com/careers, you can find out more about that.
Before we return to the interview, just a quick reminder that before the break we were talking about refactoring old code that has built up a significant number of problems, maybe written by people who are no longer available, and the techniques you can use to address that.
Clare: What common issues do you see cropping up, or mistakes that people make when they are trying to refactor?
Emily: I come back to it’s about skill. People don’t realise that they are missing a trick, that actually they are taking way too big a step and they’ve just broken the code. There was no need to break the code, there was a much safer route that they could have taken to get to that position that they just seem to be unaware of because they’ve never been shown that there is a better way to do it. They’ve never practised on code Katas or watched a demo with somebody refactoring. That’s the most common thing I see. I see somebody realise that if they want to go from A to B, they can imagine B, but they can’t see the safe route there, they just try and jump straight there. They’ve broken the code, and I’m just like, don’t do that! Stop!
Clare: You just said that people often try to do too much. I’ve definitely noticed that in myself. In fact, funnily enough, just last week I was refactoring a bit of code and I made a change. In the midst of making the change, I spotted another change, so I incorporated the new change. Which meant that now this was all spidering out into several touching bits of code. Luckily, I spotted in and thought whoa! Hang on a minute, rewind the original change, focus on the new change, make that one first and then go back to the other change that you were trying to make. Because the second one will actually facilitate the first one.
Emily: Yes. That’s a classic. Not being afraid to back out your changes and trusting that you can do that one again in a minute when you have sorted the other thing out. In fact, I should probably mention the Mikado method here, which is a method for planning large refactorings. You just said the example there where you back out the first thing and then finish the second thing. The thing is it can chain. You can discover that when you are trying to do the second thing, no actually, there’s a third thing I need to do first. The Mikado method is a way of making a map, basically. I have to do this thing first and then I can do those other things.
A lot of refactoring can be just exploring, trying to find that route to make that change safely. Backing stuff out a lot.
Clare: Tell me a bit more about the Mikado method then. How does it work?
Emily: I’m not a world renowned expert on this.
Clare: You don’t have to be a world renowned expert, it’s fine.
Emily: My understanding about the Mikado method, you’ve got a big goal for a big refactoring that you want to do. You start chipping away at it and then you discover ah, actually, before I can make this change that I want to do, there’s this other change. The Mikado method is about making a map. It’s a way of visualising that so that the whole team can see progress. It makes refactoring something that a whole team can collaborate over, over a period of weeks or however long it’s going to take for big refactoring to happen.
Clare: Yes. Also, if you’re doing it over a period of weeks but you are also following the paradigm of only ever making very small changes, always having the code buildable after each small change and the tests runnable, then that also means that you can run a refactoring parallel with business as usual. It doesn’t necessarily have to be a separate project.
Emily: Exactly.
Clare: It will depend on the code, but ideally, you should just be able to make one small change, and everything still works.
Emily: Absolutely. That’s the safe way to do it. Don’t go off into a branch, refactor the code in a branch and then think the refactoring is ready, three months later, just merge it back into master.
Clare: Yes.
Emily: I say this because I did this once, when I was very young and naïve, and didn’t know much about refactoring. I was so excited about this idea, and I could see that we needed to refactor this code base I was working on. My boss believed me when I said to him, ‘If you give me three months, I’ll go and sort this out for you.’ I sat in this branch for three months refactoring. The merge problems when I tried to go back. Why did no one warn me?!
Clare: You know what, I did exactly the same thing. You’ve just reminded me.
Emily: Really?
Clare: Yes. While I was at Late Rooms, I had an idea for refactoring. There were at least two problems with my approach. One of them was that I personally had decided that I knew what a better structure for this code would be. Really, what I was doing was making the code make sense to me. A lot of it genuinely was an improvement, but a lot of it just made it really confusing to everybody else. So, I did this refactor and then tried to merge it. Not only was the merge absolutely horrendous, partly because I had renamed everything, but also, even when other people looked at it and tried to help me, they were like, what have you done? This makes no sense to me.
Emily: Yes, don’t do that. Refactoring is a culture and a skill and the whole team should be involved.
Clare: Yes. What we’ve just touched on actually comes back to a topic that I spoke to Geepaw Hill about, which is trunk based development. I am not a fan of branches and I know that Geepaw agrees. I’m guessing you agree that if you can keep everything in one branch, then everyone is working with the same code, always.
Emily: Yes.
Clare: And you can see what impact your changes will have.
Emily: Yes. I’ve always regretted it when I have made branches in the code I’ve worked on, yes.
Clare: Brilliant. Well, brilliant because I agree. Well, I think we might have covered it all. Are there any top refactoring tips, or do you just want to summarise top refactoring tips?
Emily: Practise on code that doesn’t matter. Practise and then throw away your branch. Practise refactoring to get fluent with it. Get a teacher or a mentor to help you learn it, a coach.
The other thing that I was going to mention, something that I like to do is find a really tricky piece of code, I really like to make it into an exercise so that I can do it, practise it, show it to other people and see how they would solve it. I know this is just me, but I like collecting little exercises. I’ve got a GitHub page full of them. Some of them are inspired by actual, real, horrible pieces of production code I’ve worked on, where I’ve managed to just carve out that piece that was the interesting refactoring problem and anonymised the code to the extent that I felt it was okay to put it on GitHub. Then I can actually have this as an exercise and practise and see how other people would do this refactoring. That really interests me.
Clare: That is something that is absolutely worth plugging. Several times when I’ve been working with groups of people and I have been mentoring and running workshops and I’ve wanted a refactoring exercise, I’ve gone to Emily’s GitHub page. There are loads of them. It’s amazing, it’s a fantastic resource because not only does it have all of these exercises, but they are also all available in multiple languages. They have approval tests written for you so that you have a starting point. Honestly, it’s really an amazing resource, I can’t imagine how much work you must have put into it.
Emily: Well, I’m a coach. I use all of these exercises with my clients. By putting them on GitHub, people send me translations. I’ve got all of these language translations, but I haven’t done most of them, I don’t think. I get something back. I coach teams working in all different programming languages. So hopefully I’ve now got all my exercises in the languages I need. So yes, I think it’s a win-win, me putting all my exercises on GitHub.
Clare: Yes. Actually, that’s another really useful principle in general, that I keep relearning. That when you make things public when you encourage collaboration and contribution…
Emily: Win-win!
Clare: Exactly. It’s always good to get other people to contribute to the work that you’re doing, and to collaborate and make things open. You get better results.
Emily: Yes.
Clare: So, we are out of time now. I’m going to move onto the questions that I always ask every guest. I’m going to start with just a little game that we play. I’m going to ask you to tell me something that is true about you, and something that is untrue. Then we won’t tell our listeners which is which. We will ask them to subscribe to our newsletter if they want to know which is which. So, one thing that is true, one thing that is not true, don’t tell me which is which.
Emily: I have spent an inordinate amount of time thinking about this. I’m going to see if this one works. The reason why I started a Python user group in Gothenburg is mainly because I wanted to find a new job where I could programme Python. That’s one of my things. The other thing was the same event. I started a Python user group in Gothenburg, mainly because I wanted to have a group where I could learn how to lead coding dojos, so that I could transition to a career as a technical coach.
Clare: Okay.
Emily: Which was my reason for starting a Python user group?
Clare: So, you were either trying to learn Python…
Emily: I was either trying to find a job with programming Python…
Clare: You were either trying to find a job, or you were trying to work out how to run coding dojos. Okay, interesting. So, to end on a high, what is the best thing that has happened to you this month? It can be either work-related or non-work-related, in the last month or so.
Emily: I had a really busy September doing some coaching and also some training. The highlight was actually the training that I did. I did a course in approval testing for a small group, remote. They were so enthusiastic and interested and fun to programme with. I always love explaining about approval testing to people, because it is such a powerful technique that not enough people know. I got such a buzz from showing them how to do it, and they seemed to get the idea and be interested to try it out. So that really gave me a high, actually.
Clare: Yes, brilliant! Actually, I was going to say before, when I first came across the concept of approval testing, I thought, this is an awful lot like the golden master approach. It took me ages to discover that it just is, it is the golden master approach. Again, it’s a language thing. The word ‘master’ has got the connotation of slavery, it’s not a great word. So, approval testing is just a nicer phrase for the same thing.
Emily: Yes. And I think it just puts the emphasis in the right place, about the human step of approving the output and deciding that this is what we want to preserve as the behaviour.
Clare: Yes, fantastic. Where can people find you, and do you have anything coming up that you would like to plug?
Emily: Yes. I’ve got my website, sammancoaching.org, where I’ve got lots of materials, teaching and coaching materials to back up my books which you can find on lean pup. It’s called Technical Agile Coaching with the Samman Method.
Clare: Ah, thank you, yes!
Emily: Hopefully I am going to be running a course with O’Reilly in approval testing now. So that will hopefully get a little bit of a wider audience for these techniques. That’s coming up in the new year.
Clare: Okay. And there will be links in the show notes for all of this. Thank you very much for speaking to me.
Emily: Thank you for having me.
Clare: It’s absolutely a pleasure.
[Music Sting]
Clare: As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
What is refactoring? It’s an integral part of code development. It’s a word that can be used as a noun. A refactoring is a thing. It’s a change to the software’s internal structure that makes it easier to understand, and cheaper to modify, without changing its observable behaviour. That definition comes from Martin Fowler’s very famous book about it, which contains a catalogue of specific refactorings that can be applied.
Refactoring is also a verb that describes the act of restructuring your software.
Refactoring can sometimes become a very large project, if there is a significant gap between the design you have and the design you need, in order to add necessary features. This can involve difficult conversations about weeks of work with no visible difference. You can avoid this by constant small attention to detail, small continuous improvements.
If you are using test driven development, you might not refactor on every single test, but you should have it built in to your process.
Refactoring is broader than just those small changes you make when you are writing your tests. Refactoring is a culture, and it is a skill which is not simple. It’s a skill which is learned over time, which benefits from teaching and mentoring, from pairing with somebody who is experienced. Often, a great technique is to work as an ensemble or mob, so that you can all refactor together and see the benefit.
There are exercises, Katas that you can use to improve your refactoring skills. By doing this as a team, this means that the refactoring can be a culture which spreads to everybody. Because everybody needs to be able to do it.
When you are refactoring old code which has built up a significant number of problems over time, you can think of it as being like an old chest of drawers full of stuff. It might have been written by people who are no longer available, so there’s a lot of preparation that you have to do before embarking on a large refactoring project. You need to isolate specific areas of code. The way that you do that will be different in every case, but what you want to do is make sure that the area you are dealing with is covered by approval tests and regression tests. Be mindful of the code that is in production. Don’t assume that you are finding bugs without verifying that very carefully.
While you are refactoring, always move in very small steps. You may have to make use of existing manual testing and release processes before you have a good suite of approval tests built up. If you have access to the original authors of the code, make use of that, although you may not have that access.
You can use the Mikado method to plan ahead and make a map of your refactoring. There are common mistakes that people make when they are refactoring. Don’t try to do too much at once. Move in small steps. Don’t be afraid to rewind if you find yourself getting stuck with many changes at once. Learn how to make good use of trunk based development, rather than relying on branches and storing up future problems when you have to merge back in again.
Don’t treat it is as a sole, lone exercise. Get the whole team involved.
Emily’s top tips are to work in small steps, look for the safest route to where you are trying to get. Practise on code that doesn’t matter, or practise on existing code but in a branch, then throw it away. Look for good examples to use as exercises.
I should probably mention my own article on the subject, which is published on Martin Fowler’s website. It’s a worked example of a real code base that I was working on. There will be a link to that in the show notes.
Okay, stick around for extra content.
Clare: Every other episode, this last short segment will be devoted to story time. Storytelling is useful for teaching, for unlocking empathy and for creating a sense of shared connection and trust in your teams.
I love telling stories to both children and adults. I’m actually a lapsed member of the UK Society for Storytelling. So the plan is, I’m going to be using stories to illustrate various points about effective software development.
I make no assumptions, but if you follow me on Twitter, you may have seen me post about this immediately after it happened.
About once a year, I visit a tiny little cottage in the Lake District, on my own, for a week, to get stuff done. This year, I split the time between making musical videos for TikTok, and working on my iOS puzzle game app. It’s very remote, it’s very basic. What I do is hire a van and take with me a desk and a chair. This time, I also had a van full of computer equipment and recording equipment, and a bike for exercise.
On the way home is when the drama happened. I stopped at a service station, just a quick stop, toilet, and tea. Came outside, oh no! What… where’s the van? It was evening at about 8.00pm. There were very few cars around and it was a very small car park. I could see immediately that the van was gone. Still, I walked back and forth, up, and down. Surely it must be hiding behind another vehicle. But no. It was gone. But… but… what about all my stuff? I was thinking, how will I get home? All my work!
There was no internet at the cottage, so nothing I had done had been uploaded to the cloud yet. It was all lost. Hours of recording of audio and video. Hours of code written, bugs fixed, new features implemented, all lost. I finally realised I was just going to have to ring the police. By this point I was hyperventilating. But I was thinking, okay, what do I do? I ring 999 and maybe they can find it on their cameras. Maybe they can stop it on the motorway. I mean, how do people even steal vehicles anymore?
It was definitely locked. I had the keys in my hand, and I could remember locking it. So, I rang 999 and I got a lovely, kind woman on the other end of the phone, to whom I will be eternally grateful. She was checking was I absolutely sure that the van was gone? Did I have the key to it? The answers were yes and yes. Where was I? I told her I was at Lancaster Services, and she was checking did I mean Forton? I wasn’t even sure that was what it was called. I was saying, ‘It’s the one with the tower.’ I was looking up, I was standing in the car park, and I could see the tower, towering over me.
She was trying to calm me down because the full enormity of what had happened was hitting me. I was still pacing up and down the car park with the phone. She put me on hold for a while. I was thinking it just seems so crazy, surely the van can’t have gone. But it definitely wasn’t there. I was thinking could it somehow be somewhere else? But how? That was definitely the car park. I could see the exit going off to the motorway and I had a clear memory of entering the service station at the door that I could see. So, I was thinking could there somehow be another car park around the back somewhere?
I was so sure that there was only one car park. Until… oh. Ah, okay, hang on a minute. Of course, there is one other car park. An identical one, on the other side of the motorway. Then I remembered. When I entered the service station, there was a sign telling me that if I wanted tea or coffee, I would have to cross the bridge to the other side of the motorway, which I had completely forgotten about when I came out carrying my tea, and just exited straight into the car park on the wrong side of the motorway.
Of course, if I had thought about it, the tower was my clue because it was on the other side of the motorway. I was still on hold to the emergency services, but I was already straight back inside the service station, crossing the bridge. Sure enough, there was the van. The operator came back on the phone, and I explained. She was so kind and sympathetic, bless her. She told me this kind of thing happens all the time.
So, what can be learned from this story? The obvious thing is don’t make assumptions. There’s the basic principle of Occam’s Razor, which tells you what is the simplest, most likely explanation for what is happening? The big thing is don’t panic. I know that’s easier said than done, but as soon as you start panicking, you stop thinking. I wasn’t thinking clearly. It took me a long time to work out what had actually happened because I was panicking, and I wasn’t thinking effectively.
The last thing is something that I confess I do struggle with. It’s so useful, particularly when you are in a difficult situation. Take a step back and look at the bigger picture. In this case, literally the bigger picture. If I could have raised up into the sky and looked down with a bird’s eye view at my surroundings, I would have seen the identical car park with the van in it. I could have done that within my head as well. Obviously, I’m not suggesting that we should all learn to fly.
So anyway, it took a while for the adrenaline to subside. But hopefully you are as glad as I am that this story has a happy ending.
[Music Sting]
Clare: Working in the public sector means that at Made Tech we really care about making a difference. So, for this final, making life better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place.
I have Kayleigh Derricotte here with me. She is a Delivery Manager here at Made Tech. She is going to give us a bit of advice about… well, I don’t want to say it in my words. What are you going to give us advice about, Kayleigh?
Kayleigh: I’m going to give you some advice about how to interact with colleagues or friends who have differences from you.
Clare: Fantastic, thank you. So, what is your advice?
Kayleigh: My advice is to hesitate. I think a lot of people say things immediately as they come to mind, and afterwards there is some scrambling to take things back. Often the damage is already done. As the person who is receiving the uncomfortable comment, it can be much more damaging then, the moment of discomfort that you feel saying the uncomfortable comment.
So, my advice is to hesitate and really think about whether you are saying this thing because of the difference you have with this person. In my example, are you asking me a question, or saying something to me, because I’m black or because I’m a woman? If it is because of one of those specific things, then question whether you actually still need to say it.
Clare: Yes. Do you have any examples?
Kayleigh: The classic example which I think not just black people, but most non-white people will have heard is, ‘Where are you from? Oh, no, where are you really from?’ So, if I answer, ‘I am from London.’ That should be sufficient. If a white person had given the same answer, that would be the end of the conversation. The follow up question is where the hesitation should come.
Are you asking where am I really from because it’s important to the conversation we are having, or because I am black and that intrigues you? If it’s not important to the question we’re having, don’t ask the question.
Clare: Yes, absolutely, thank you. That’s really helpful.
Kayleigh: No worries.
Clare: And that’s the end of another episode. If you are enjoying the podcast, please do leave us ratings and reviews because it pushes us up the directories and makes it easier for other people to find us.
I’ve got a few talks coming up. You can see the details on my events page on Medium, which is linked to from my Twitter profile. You can find that at @claresudbery, which is probably not spelled the way that you think. There is no ‘I’ in Clare, and ‘Sudbery’ is spelt E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter @madetech, M A D E T E C H.
Do come and say hello, we are very interested to hear your feedback and any suggestions you have for any content for future episodes, or just come and have a chat.
Thank you to Rose, our editor, Gina Cady, our virtual assistant, Viv Andrews, our transcriber, Richard Murray for the music – there’s a link in the description – and to the rest of our internal Made Tech team; Kyle Chapman, Jack Harrison, Carson Rob and Laura Plaga. Also in the description is a link for subscribing to our newsletter. We publish new episodes every fortnight on Tuesday mornings. Thank you for listening and goodbye.
[Recording Ends]
Back to the episode
