Martin Fowler Reflects on Refactoring: Improving the Design of Existing Code

Carter Morgan (00:03)

Well, Martin, thank you so much for joining us today. It's great to have you here.

Well, I've had a lot of great response because I'm on Reddit a lot. This is a secret to anyone who listens to the podcast. I pay for an app that gives me notifications whenever anyone mentions on the programming subreddit, the keywords like book or podcast or whatever. And so I try to get in to respond quick. so usually people are asking, well, what's a good book to read? And I almost always recommend refactoring. that is out of all the books I recommend,

usually the one I've seen that gets the best reaction. People say, gosh, I read refactoring years ago and loved it. So it's got quite a bit of following. so we don't think it's a fossil at all. We think it's just as applicable today as it was when it was written.

Well, why don't you talk to us a bit? We read the second edition of Refactoring, you, when was the first edition written? Was it like 1999 -ish? In the late 90s. So maybe, maybe you can give us kind of a two -part answer to this. We'd love to know why you were motivated to write it in 1999. Maybe describe the computer science industry back then, but then also let us know why you felt the need to do a second edition more recently.

We, yeah, reading this book was a big eye -opener for me. I don't know. I think I thought for a while, like if any system is complex, that means it's scary to change. And so a system being scary to change means it's complex. And if we're doing complex things that must be mean we're being good engineers, right? And yeah, it was, was this. And we also read working effectively with legacy code, which I believe we got as a recommendation from this book.

And Nathan pointed out in the podcast that there's actually a circular dependency because working effectively with legacy code recommends refactoring. But we, yeah, where it really clicked to me that like, you don't need to be scared about changing your code and that there are solid, effective strategies that you can employ to gain that control over the code base.

Absolutely, absolutely.

Yeah.

It's true, we haven't.

-huh.

And I think it's a great way to illustrate the value of unit testing. know that unit testing, especially amongst newer developers. remember that was one of the first questions I asked my internship to the senior engineers. said, why do need to unit test? Don't I know it works because it, like I clicked the buttons and it does what it says it's going to do. And even though senior engineers, I don't think I've thought about it in the way you thought, because I think there is some truth to the idea of unit testing. That's like, if you view it as ultimately like, this is the thing we just have to run before we send it off to the bill to kind of.

make you do a bit of a sanity check. Like unit testing, think can seem like a lot of effort expended for little value returned. But if you instead view unit testing as this is the harness I can put around my code that can make me confident in refactoring it, to me, that was a real eye opener. And all of a sudden the value I'm getting out of unit and tests increased 10 fold.

Absolutely.

Not in the way you recommend it. Like obviously I've seen code and thought, okay, you know, this code will be cleaned up and it could look a little better. And then you, ⁓ and then you try to clean it up, but it was always the code. would try to clean up. was always kind of like in proportion to how vital it was. Like if this was a centerpiece of the application and critical to the business logic, I would not touch it because what's the point in making it cleaner if it's going to break everything.

Right. But if it was anything kind of around the margins and if I could kind of test it fairly easily after my logic, I would, you know, I, I'm a boy scout, right? So I was always taught like with campsites, like leaving better than you found it. And I try to have that same thought with my, with the code base, but I think I also kind of thought like, well, you're definitely not leaving the code base better than you found it. If you break everything and yeah, these critical pieces are really subject to being broken. So again, there was just this thought of like,

better safe than sorry here. So I was familiar with the concept of refactoring, but I think I was very scared to apply it to anything business critical.

And it did directly influence how I do it now. And I think I even shared on the podcast a story where I was working with an Apache Beam pipeline and we had one of those things where it was like, one of those kind of like, what's the word for it? I think it's like exclusive if, or some kind of like anti -pattern where basically like it was one of those things where it was like, if customer ID is equal to this, then do this. Like one of those basic like use cases built in. And I saw it I'm like, ugh, like that's not.

Like it'd be, it'd be better if we can move this to some sort of like config value, you know, approach. ⁓ so we don't just litter the code base with ifs, but I looked at it I was like, well, this is a nice to have, but I don't want to modify it because again, what if I break the pipeline just to like make this nice to have? And then I remember like, wait a minute, I can be confident in this. And I wrote up a test to validate that it would work properly, swapped it all around, ran the test, valid it, you know, and then everything was green.

And yeah, and I was off to the races. So that was an example just recently where, I mean, that was a direct result of having red refactoring. And I think before I would have just said, well, it'd be nice to change this, but why risk it?

Absolutely, absolutely. I mean, something you talked about with...

The idea of software estimation, And how, because I think that's kind of critical to the idea of refactoring is the idea that the requirements keep changing and we need to be able to build our code in such a way that can conform with these changing requirements. It's interesting. My wife is actually pursuing a degree in computer science right now. So she's just starting programming. And as she's been doing it, she says, it's surprising because the things I thought wouldn't take a long time.

are taking a long time, know, when she's working like a personal project. But then this thing I thought would be really hard is really easy. And I kind of told her, I'm like, we've been trying to solve that problem for 50 years to be able to accurately measure and scope how long it takes to build a software project. What is it about the field of software engineering? Do you think because like you mentioned, it's different from like, you know, hard engineering that makes it so difficult to

Understand how complex or how long something's going to take.

Wow.

How do you build that kind of trust?

Hahaha.

I genuinely think that it's funny because, well, and so maybe I'll ask you a question before I answer your question. As far as you know, are you the person who invented the term refactoring? No, okay. Okay, gotcha. So your book is just the roughly authoritative source on it, but you had heard of the term refactoring beforehand.

-huh.

interesting.

So to answer your question, have the term refactoring. I think if I said that to any programmer I've ever worked with, like I'm to refactor my code, everyone knows what that means. And everyone knows that means to, I mean, roughly to make your code better or more maintainable or manageable. But I mean, again, after reading this book, like, ⁓ I've been fortunate to work at some well -known places. I've worked at some, some big tech companies, some, a lot of

places you've heard of and at those places I've been really fortunate to work with really, really good engineers. And so I think that's what surprised me when reading this book because despite having worked with lots and lots of great engineers over the course of my career, I have never heard someone kind of make that connection. Again, like the importance of testing when refactoring your code, right? Like I have never, again, like to me,

It was a real libel moment. and so like, obviously I've heard people say like, I'm going to refactor this code, but the refactoring is always referred to changing the code to make it better. It's never been a holistic process that mean that either means relying on the tests strongly while making these changes or perhaps writing new tests to validate these changes. ⁓ and I'm sure that maybe some of the more like senior principal engineers, maybe they just understood that implicitly.

certainly not the more run -of -the -mill engineers, but it's one of those things where it's like, even if maybe some of the more senior folks understood it implicitly, this knowledge was not being passed down and communicated to the more run -of -the -mill engineers that you cannot refactor safely without tests. And for me, it took until reading the book to make that connection.

You

We've really enjoyed that about the podcast. I think there's like a fair amount of virtuous cargo colting going on in the industry, I guess is how I put it. We're like, it's good to write tests. And people, if you ask them, say, it good to write unit tests? They say, of course. You can't ship without a unit test. having unit tests is better than not having unit tests. But then I think if you ask people, why do we write the unit tests? And I kind of said at the beginning, I think most people would say,

Well, you know, it's a nice little check that everything's working before we deploy, right? But then, again, not realizing that, no, it's also a way to be able to refactor your code. Yeah, I think there's, it's interesting because I think a lot of people will kind of hide behind like, this is a best practice. And I think what's funny about that is a lot of times when people do say this is a best practice, they're usually not incorrect. Like logging is a good best practice, right? You know, but then,

Not necessarily knowing what's the actual reason. What's the philosophy behind that? You know, that was actually one thing I discovered when reading working effectively with legacy code is I kind of looked through like some code base. I'm like, why is everything abstracted behind an interface? Like, just give me the class, right? And then reading about, kind of that inversion of control and then the ability to to swap these things out for mocks and stubs and testing environments, right? And so I think there are.

And I've also run into some developers who kind of just by nature, especially like a Java environment, everything is put behind an interface because they've seen that for a long time. And that's just what good Java programming looks like. But I don't think could tell you the reasons behind why they do that. So we've really enjoyed reading all these books for the podcasts and just realizing, you know, it's, it's kind of great because it was like either we come and realize we're doing things we shouldn't be doing and find out why we're not doing them. And even if we read things that we are doing.

We often find out the more holistic reason behind why you should do those things. So it's just been, yeah, it's been fascinating reading all these books and kind of coming to those conclusions.

-huh.

interesting.

Yes.

I can't remember where I read it. in this book. It might have just been a Twitter post for all I know. But it was, I think it was a discussion of is there anything you should always do no matter what programming project it is? Cause kind like you're talking about like sensible defaults versus a best practice and the consensus opinion was version control. They said that is the one thing you should have in every project, but everything else. Yeah.

Yeah, yeah. So.

Yeah, honestly.

and, I really like that framing of sensible defaults because I get what people are getting at with best practices where there's this idea of like, listen, let's not reinvent the wheel here. Lots of people have been in this industry for a long time and it would be silly to throw out the accumulated wisdom of all of their mistakes in favor of, you know, some bold new approach. But I like that framing of sensible defaults, which is like, this is a good starting place. Let's assume that.

this is a fine path to take, but should we be able to justify a different approach, there's no reason we can't do that. Because like you say, a best practice, you can't beat a best practice.

Well, we'll Chris in here on the Book Overflow podcast, there is a best practice. It is version control and you are allowed to.

Yeah.

Aha.

Yeah.

You

What's your thought on the legacy of your book? It's been around a while. mean, refactoring it. And like I said, when I mention it on Reddit, often it gets a very strong reaction, a very strong positive reaction. What's your take on the legacy of refactoring?

-huh.

Hahaha

I mean, I think it's about as close out of all the books we've read on the podcast where I would recommend it as almost mandatory reading to any programmer. And we don't mean that as a slight to some other books. Like we, we loved working effectively with legacy code, but there's a truth that like, well, you know, if your code base is in a solid shape, maybe this isn't the most effective read for you. We read slow productivity by Cal Newport and it's like, well, if you're a junior engineer and you don't have as much control over your free time, maybe this book wouldn't resonate as much. I mean,

I can't think of a single engineer I wouldn't recommend refactoring to. I guess someone who's already read it multiple times is kind of the only person I wouldn't. So I think it is out of all the books we have covered, it is one of, if not the most evergreen broadly applicable books, which I think is very impressive.

It's a good question. Nathan, you want to give your take on it first?

I can give a broader answer and then a more kind of software engineering focused answer, which is, I think we live in a world dominated by short form content, right? Things like the rise of like TikTok and YouTube shorts in some ways concern me just because it's rapid information. I am on Twitter and I like Twitter for checking in.

and like keeping up with, you know, new ideas that may be coming out or the news, you know, I try to follow accounts that I tend to trust. ⁓ and for five minutes, it's great. If I scroll Twitter for an hour, I feel like my brain is melting out of my ears. Right. My, my wife and I talk about, have four sons and they like video games. And we kind of talked about like, what's our philosophy on video games. And I played video games growing up. But when I was growing up, video games were like, they were something that could be completed. And I have a lot of fond memories of like.

finishing a game like Super Mario 64 or The Legend of Zelda Ocarina of Time and bringing all my brothers in to say, I'm gonna fight the boss, everyone come watch and then you beat it and then the credits roll. And you can appreciate as this complete work that a lot of people, it's a work of art. And I just think we increasingly live in kind of a world where content is so disposable. There's just an unending feed of short form content you can consume. And so...

For books in general, the base of it is just, I know how I feel after reading a book for an hour versus scrolling Twitter for an hour. And I feel great after reading a book. I feel educated and uplifted. Twitter, feel like garbage. And then books for software engineers in general, because it was something we had debated when we were starting this podcast is, as a tech dominant media or discipline like ours, what

what is the purpose of a dead tree kind of book? But I've really found that as you engage and grapple with an idea over a week or two or three, it's surprising how much you realize, even if you thought you understood this idea, you actually didn't, or you learned new things about that. And actually, think refactoring is a great example. Because if you said, Carter, do you believe in refactoring your code? I'd say, Of course we should refactor our code, right?

And if you had asked me if I understood what refactoring meant before reading this book, I would have said, totally. Yeah. You you just, change the code, you make it better. ⁓ but it was only after spending a week really engaging with this book where I realized, like I, I don't. Yeah. I don't know as much about this as I should have. And there are just so many books we've read where even if they're, I think, again, their ideas that if they were scroll by my Twitter feed, I'd say, God, and I agree with that. But then after engaging with it for a long time,

you either develop a more complete understanding of it or realize that maybe you were mistaken. so yeah, I mean, we kind of started this podcast with the books almost as like, as a bit of a gimmick because we thought, Hey, this will be a great way to supply a good steady feed of content for discussion. But as we've gone on, I've just really become to believe, I've come to believe that it's a really like, it's almost like a shortcut to leveling up your career and your understanding is engaging with, ⁓ with long form ideas written by talented authors in their books.

Mm

Yeah.

a while.

Hmm.

You know, and it's funny, and this is something we've picked up with other authors is obviously when you're working with a publisher, there's the demands of the publisher and there's not nearly as much freedom as just, I'm just gonna put on my blog and it can be whatever I want. And so for any author who says, I'm not gonna write a book anymore because that's such a hassle and it's like, on my blog. Like, I totally get it. We just have the good fortune of consuming it after, you know, the sausage is made. you know, we have, and certainly if someone were to come to me and say, you know,

Carter, I'm going to read this book. I'm going to read this, you know, 40 page essay on Martin Fowler's website. What should I do? say, you're you got to read a book. Are you kidding me? You can't read, you know, I think more what we're trying to encourage people to do is they're so it was one of the big motivators for making this podcast is we noticed that there at least in the podcast market, there was a gap for consistent substantive technical discussion. There's a lot of

let's talk about the latest controversy of the week programming podcasts, right? And there's even a lot of like interview other programmer podcasts. But there aren't a ton of podcasts where people say, okay, let's just spend the whole time talking about refactoring. Let's spend the whole time talking about pair programming. And that's also really hard to do if you don't have a good base of material to be drawing from. And so we've actually been really happy as we've done this podcast that we...

We always write up our notes beforehand of kind of all the things we want to hit. We never hit everything that we want to talk about. And so we hope that our audience finds it nice and substantive. And I think that's more what we were aiming for with the books is just, yeah, how can we create content that

Goes deeper than the surface level and for us Reading books has been a great way to do that but I also you know you say like most people abandon after 50 pages and like Lots of the books we've read I would have been in the exact same boat But I have to keep reading because we record every Wednesday, right? So ⁓ and I don't think that's ⁓ I just think it's the nature of technical reading. It's hard. It's challenging, right? ⁓ so

We hope we encourage more programmers to read more, whether or not, and again, it's not so much you have to read these books for reading. If someone was listening to this podcast and is inspired to go read every blog or blog article on martinfaller .com, we'd consider that a huge success. I think it's more like get out of Twitter, get out of YouTube shorts, get out of the 10 minute reaction videos on YouTube, right? Engage with ideas at a more substantive level.

And that's what we're hoping people do when they listen.

Absolutely.

We'll have to circle back with you in email and see, and see if there's anything you would recommend off the top of your head for that, because we have talked about in particular, I'm wrapping up my master's degree next semester and taking one of the most difficult classes in the program. And so we've discussed like maybe one week we won't cover a book, but instead we'll cover a notable essay, right? Just to bring the reading load down a bit. So we'd love to get your opinion on some of what you think are the best essays or blog posts to cover, because we've discussed that.

I was doing that on the podcast.

Well, mean, Martin, thank you so much for coming on. I mean, it really has been such a pleasure having you. We always like to ask our authors before they leave, is there anything you've been reading lately or anything just that you would really recommend to our readers?

that's so nice.

Mm -hmm.

Interesting.

Hmm.

That's fascinating. I had never made that connection. And I'm disappointed with myself for not recognizing the Sullivan case, because they did constitutional speech and debate in high school. But it's, yeah, I'll have to give that a look, because I am a big fan of constitutional law, and I'm a big history buff too, especially 20th century American history. So yeah, that's a great recommendation. I'll have to check that one out.

Well, thank you so much for stopping by, Martin. We really, really appreciate you coming on.

Yes.

We have been pleased at the amount of people who will comment on Twitter or Reddit and say like most podcasts are dumb, but you guys made a good one. Like, hey, it's a very disposable medium. I know. Well, you can find us on a book overflow on YouTube at book overflow pod or on Twitter or X or whatever you want to call it at book overflow pod as well. I'm at Carter Morgan on Twitter. You can find all of Nathan's newsletter.

links for functionally imperative at www .functionallyimperative .com. Martin, there a, do you want to plug any of your socials or you keep a low profile?

Hahaha

Well, fantastic. the book, as we've talked about this whole podcast, it is Refactoring by Martin Fowler. We'll include a link in the description along with links to the other books we've mentioned in this podcast. But thank you so much for stopping by, Martin, and thank you listeners for tuning in. We'll see you around.