PostHole
Compose
Login
SE Radio 656: Ivett Ördög on Rewrite versus Refactor
Ivett Ördög speaks with host Sam Taggart about rewrite versus refactor -- a choice that many projects face as they grow. It's a topic that inspires a lot of dogmatic feelings. They discuss how companies and projects end up at this crossroads and consider some strategies to try to avoid it. Ivett challenges the myth that you should never rewrite but points to two key factors that need to be present for a successful large-scale rewrite or refactor. They end by talking about how to get management on board for such large-scale rewrite or refactor projects. Brought to you by IEEE Computer Society and IEEE Software magazine.
Ivett Ördög speaks with host Sam Taggart about rewrite versus refactor — a choice that many projects face as they grow. It’s is a topic that inspires a lot of dogmatic feelings. They discuss how companies and projects end up at this crossroads and consider some strategies to try to avoid it. Ivett challenges the myth that you should never rewrite but points to two key factors that need to be present for a successful large-scale rewrite or refactor. They end by talking about how to get management on board for such large-scale rewrite or refactor projects.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
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:19 This is Sam Taggart for SE Radio. Yvette Ordog is the creator of a gamified DevOps training tool called Lean Poker. She has over 15 years of experience in software development and leadership. And today we are going to talk about rewrite versus refactor. We’ve talked about similar subjects on the podcast previously in Episode 615, Tidy First, 638 Architecture Modernization and 625 Automated Refactoring. Welcome Yvette.
Ivett Ördög 00:00:44 Hi.
Sam Taggart 00:00:46 So you have some unconventional views around the refactor versus rewrite debate. Before we get to that though, how do we get to this decision point where we have to decide whether to rewrite or refactor?
Ivett Ördög 00:00:58 I think that one of the core issues with software development is that we tend to have these emergent systems and as we develop them over time, they get so complex that we lose track of it and it becomes really hard to maintain and there are a lot of ways we can avoid that. The problem is that those ways are expensive and I think this is the controversial part where I’m saying that yes you can actually keep a system clean enough that you can always move fast, but that effort of keeping the code base clean is a non-zero effort, which is too expensive for small companies, which leads to the consequence of almost every single successful company having a code base that is considered legacy or considered something that most engineers don’t really like touching.
Sam Taggart 00:01:53 Yeah, that was going to be my next question. So how does this relate to the term legacy code? What exactly does that mean to you?
Ivett Ördög 00:02:00 Yeah, so I really like the definition of Michael Federer’s that any code that doesn’t have tests is legacy code. I feel like it’s not complete. In the context of his book, that definition absolutely makes sense, but I have seen code bases that had tests and were still really hard to maintain or even add features to. So I think that the better way of looking at it is basically legacy code is code that I feel uncomfortable working with and that is kind of a more general definition for me also because like I have seen code bases that didn’t have tests and I was still comfortable working in it.
Sam Taggart 00:02:42 Yeah. So can you dive into that a little bit? Can you give some examples of some code bases that had tests but were hard to maintain?
Ivett Ördög 00:02:48 Yeah, so the code base that we struggled with was a PHP legacy code base and part of the reason it was really hard to work with is because it was started by a bunch of junior engineers without any adult author or oversight. So they basically ended up creating this really hard to maintain code base where logic was intermixed with templating and with database interactions and everything. And over time we started adding tests to it. But honestly like when you have that level of complexity just mixed up, even adding those tests can only help you so far, right? You still need to refactor a lot and sometimes even if you do refactor you might end up with like a system that is logically insufficient in the sense of, so the specifically example I want to give is an import process that we had and that import process was meant to process a CSV file and then move all the data from the CSV file into the database. Unfortunately the way this was implemented is to move everything field by field, not even line by line. Like every single field update was a separate SQL query with lots of round trips, to the database. And solving that issue is a bit more than refactoring, right? Because we do need to change the behavior of the system. And how do you do that without actually writing the whole system? That was the question that we had to answer.
Sam Taggart 00:04:24 In that case, I would imagine the test may have gotten in your way as well because we’d have to rewrite the test to change the system behavior.
Ivett Ördög 00:04:30 Yes. Luckily, we didn’t really have unit tests. I say luckily exactly because of the reason what you said, it would be hard to not break those unit tests while you are doing something like this. We had more like end-to-end tests and those were a bit more reliable because we didn’t have to like it didn’t touch the internal logic of the system, it was just actually importing a CSV file and then checking the database. So that was helpful. But having said that, we did need to seriously rethink the system and have a completely different approach for loading that data into the database.
Sam Taggart 00:05:10 You also mentioned that you’ve encountered some code that did not have tests but was easy to refactor. What made that easy to refactor?
Ivett Ördög 00:05:17 So one system that was fairly easy to refactor actually it was a system that had a backend in the front end. And interestingly the front end was horrible and really hard to work with because it was just really quickly, it was actually my own system I wrote were a few days because I had a deadline coming up so I just rushed it all together. So the front end was really hard to work with, but the backend was actually fairly clean and also it didn’t have any tests. And the reason it was really easy to work with backend was because even though it didn’t have tests, I kind of had a dashboard as part of the front end that showed everything. So when I reloaded that page, I immediately could tell if every single part of the system is working because that single page was kind of a test. Of course it required me to know what to expect on that page, right? But it was enough for me to have a basic level of feedback that is enough for me to work with.
Sam Taggart 00:06:17 Okay. Another term that gets thrown around is technical debt. How does legacy code relate to the term technical debt?
[...]