PostHole
Compose
Login
SE Radio 602: Nicolas Carlo on Improving Legacy Code
Nicolas Carlo talks with host Sam Taggart about Nicolas's recent book, Legacy Code First Aid Kit. They start by defining legacy code and the general issues that developers face when dealing with it. Nicolas describes some of the tools in his book and provides examples of where he has found them useful. The episode also touches briefly on the role of AI and some other tools Nicolas has discovered since writing the book. This episode sponsored by WorkOS.
Nicolas Carlo talks with host Sam Taggart about Nicolas’s recent book, Legacy Code First Aid Kit. They start by defining legacy code and the general issues that developers face when dealing with it. Nicolas describes some of the tools in his book and provides some examples of where he has found them useful. The episode also touches briefly on the role of AI and some other tools Nicolas has discovered since writing the book.
This episode is sponsored by WorkOS.
Show Notes
SE Radio Episodes
- 363 – Jonathan Boccara on Understanding Legacy Code
- 295 – Michael Feathers on Legacy Code
- 587 – M. Scott Ford on Managing Dependency Freshness
- 595 – Llewelyn Falco on Approval Testing
Other Resources
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Sam Taggart 00:00:53 For our Software Engineering Radio, this is Sam Taggart. I’m here today with Nicholas Carlo and we’re going to talk about his book Legacy Code First Aid Kit. Nicholas is a freelance web developer who loves building communities and maintainable software. He organizes the Software Crafters meetups in Montreal, Canada and shares tips on how to work with legacy code on his blog understanding legacycode.com. So welcome Nicholas.
Nicolas Carlo 00:01:17 Hi Sam. I’m happy to be here with you.
Sam Taggart 00:01:20 Great. So the first question is, your book is called Legacy Code First Aid Kit. How do you define legacy code?
Nicolas Carlo 00:01:28 That’s a good question. So I think most people, well most people will define legacy code as some old code, which is not my definition. A popular definition of legacy code is also Michael Feathersí definition, which is any code that is not tested and it’s a great definition in most cases because in general you are working with code that is not tested. I have a slightly different one because I want to capture some nuances. My definition is legacy code is valuable code that you are afraid to change, which may be because it’s not tested, but I’ve seen some tested code that would still level as legacy. And also, I like to emphasize first on the fact that if you’re dealing with legacy code, it means that you’re maintaining a code that is impacting people, it’s using production, otherwise you could just throw it away and do over and it’s generally not a scenario. So it’s a valuable code in most companies there are successful, you will have legacy code that also pays for the salary. So yeah, I like to think about legacy code as, something you must maintain. It may be a challenge and painful we’ll talk about that, but also it can really have a lot of impact on actual people.
Sam Taggart 00:02:47 Yeah, you kind of answered my next question, which was how do you decide when code is worth saving and refactoring what should be thrown away? But there is another part to that question which is, are there times when you should take legacy code and maybe it’s okay to just slap some duct tape on it and keep it running as opposed to doing a real refactoring and really fixing it up and modernizing it?
Nicolas Carlo 00:03:08 Yes, a lot of the answers will be it depends, but I’m going to try to explain what it depends on and what to do. For rewrite versus refactor, yeah in general, rewrite is a bad idea. It has been detailed in many posts, but the only moment where rewriting the thing is a good idea is either you are building something new so it’s more of a like a new product and there is a talk from DHH, creator of Ruby on Rails who was like, okay, but rewrites are fine, et cetera. And when you dig into it you realize, okay, he’s talking about building a whole new product based on what you learn on the first product. But in this case a rewrite is fine. The second scenario is when the rewrite is very small that it wouldn’t be worth iterative approach. And that’s the trick for large systems is to make a rewrite small enough.
Nicolas Carlo 00:04:03 So you take a small chunk of, for example, a monolith, you take a small chunk that you identify and your scope is to rewrite that part and then you have strategies in place to ship to production this new maybe microservice along the legacy code base and have all of that working in production together. So in a sense you could consider it’s a rewrite, but it’s a rewrite of a tiny chunk and that’s how you should address legacy code bases. When is it not worth doing any kind of iterative improvement? I don’t know. I would say you probably need to be careful when you do not have, tests in place. For instance, about the changes you are making. The first thing you will need to do when you rewrite a legacy code base is put in place safety nets. So automated tests, lost documentation, lost knowledge, try to recover that, monitoring also logs all of these, if they are not in place, you should start by putting them in place before you make meaningful changes. Otherwise you risk wrecking a lot of stuff without even realizing it. So that will be the scenario where before trying to refactor the whole thing, I will just make duct tape minimal changes on it.
Sam Taggart 00:05:25 Yeah, I remember seeing an interesting post where somebody said something about if you’re going to rewrite something, reimagine it. So like take kind of like the DHH quote where you take what you learned, and you just write something new that does whatever it is you would do now. And I think that could be worth it too. I mean I think part of the problem seems to be risk refactoring always seems like a less risky option in my mind.
Nicolas Carlo 00:05:48 Yes. Also risk and we underestimate the rewrite project because it’s like with AI. AI can help working with legacy code basis, but as a support tool, if you hope to just use AI to refactor for example, a piece of code you do not understand, the problem will be, you cannot evaluate if that’s correct. And that’s the same for rewrite because how can you tell if the new rewrite actually does what the old system does? And there will be a lot of surprises because all the context you have lost, it’ll be revealed to you and it’s better to have it revealed progressively in small chunks rather than with a big bang scope. We had that story. So I work and live from, Quebec in Canada and early this year the part of the government that is responsible for the cars and all this. So they have a system, legacy system you can imagine, and they went to modernize it and they announced, hey, we’re going to shut down the services for like three, four days and we’ll be back up and it’s going to be whole new and magical.
[...]