When You Should Maintain, Refactor, or Rewrite

Let’s talk about refactoring versus rewriting code. In general, our bias is to preserving the maintainability of a legacy project, but when that simply isn’t possible, then we start analyzing the need to refactor or rewrite.

Full Transcript Below: 

Cris:

Refactoring versus rewriting of code.

Cody:

Refactor in terms of a computer science term, usually just means we need to change something within another thing.

Cris:

Is it the whole project, or can you just rewrite sections of an application? How do we start to differentiate and determine whether we need to refactor the code or rewrite the code?

Cris:

All right, Cody, today we’re in the studio and we get to talk about refactoring versus rewriting of code. What are the differences? What are the benefits? Why would you do one versus the other? So we’ve talked in the past of course, about our code audits that we do here at Bixly. If you have a legacy project, being one that has existing code already, you come to us, we’re going to start by doing an audit of some sort and figuring out what’s actually going on with your code base. So when we get in there, what do we actually do with this code? How do we start to differentiate and determine whether we need to refactor the code or rewrite the code?

Cody:

Well, the first thing among this whole audit process is obviously going to just look at the code, understand it, look at documentation. Hopefully there is some.

Cris:

Hopefully.

Cody:

Fingers crossed, right? But the goal here is that really both of those are bad scenarios to be in a lot of the time. Whenever you have a legacy project and you hear the words, refactor or rewrite, a lot of the times people have kind of a hip shot reaction. That’s going to be like “That’s money”. And so when we do that first audit process, the main thing we’re trying to figure out is not whether we should rewrite or refactor. It’s to see if we can actually understand the maintainability of the project as it currently is. And when we determine in situations where a legacy project, one that’s been around for a long time, doesn’t really have the, I guess you could say the shell or bones necessary to be a production like enterprise-grade application, client-dependent on what they actually need to use it for, that’s when we start recommending a refactor or rewrite. And the difference between the two is-

Cris:

I was going to say, “Yeah, what’s the difference?”

Cody:

Let’s get back to the refactor versus rewrite. A refactor is usually a partial rewrite basically, whereas a rewrite means typically we’re completely redoing it from scratch.

Cris:

Is this the whole project, or can you just rewrite sections of an application?

Cody:

It’s possible but that is effectively refactoring at that point. A rewrite typically in terms of whenever it says, “Hey, we need to rewrite this whole thing.” Usually that’s the context is that we need to do the whole thing if the word rewrite is being used, whereas a refactor in terms of a computer science term, usually just means we need to change something within another thing. We’re changing a factor of the application.

Cris:

We got the car, it needs new tires and needs the oil changed and you should probably look at the brakes.

Cody:

Correct. Yes, exactly.

Cris:

As opposed to you should probably just get rid of this sprinter van because it’s just isn’t working out for you.

Cody:

Yeah. So to kind of dial that back down is a refactor will be determined to be the right choice if an area of the application is troublesome or unmaintainable versus a rewrite is when there are systemic issues that cannot be fixed, or I should say cannot economically be fixed by refactoring so much of the application that you end up with a rewrite anyway. So that’s basically the difference there.

Cris:

And here at Bixly what is our stance on when we get a code base? I mean do you feel that our development team tends to be very lets refactor rewrite heavy or do we lean more towards the idea of “Let’s see if we can keep that legacy project going.”?

Cody:

For one, it’s going to depend on client needs every time, which is usually the answer to a lot of these questions. But from a bias standpoint, we always try maintainability first. We try to actually take what we’re getting, understand it as best we can, and then go forward with that to try and improve it over time, along with new features or whatever the other goals may be. So in a general sense, we do try to avoid refactors and rewrites as necessary, unless it really just is not maintainable. And that can happen depending on the history of the project. So when it comes down to that, we’ll recommend it, but we try to not if we can.

Cris:

Yeah. Cause I mean, there’s these larger business considerations that we always have to take into account when we’re affecting our decisions. So what are some of these business considerations that come through that we’re like, okay, well, “Here’s why we might want to try and work with it” or “Here’s why we might want to actually rewrite or refactor”.

Cody:

Well, I think it’s going to come down to the business’ goals for the project. If you need something that is extremely stable, like Uptime 99.99%, and you just have code that isn’t effectively maintainable because it has too much complexity, it’s not documented well, or it’s using legacy packages that don’t exist anymore, that would be a strong case to refactor or rewrite a large portion of the application because you as a product owner expect this thing to be up and working as often as possible because either that’s the goal of the application or you have essential business needs that rely upon it.

Cody:

Now that said the considerations of the actual project scope. If you don’t care, if the application crashes sometimes why refactor then? If it’s already designed to be unstable and you’ve accepted that that’s going to be a thing like it’s just an internal business tool for a couple of people in the department to use, you probably don’t need to worry about it too much and you can kind of just accept that it’s not going to be very stable. It depends on your goals there. And then abstracting away from, okay, what are the actual goals of reliability? The next one is obviously budget because.

Cris:

Right. Price. Budget, yeah.

Cody:

It gets extremely expensive to refactor or rewrite an application.

Cris:

And time too.

Cody:

Yeah, yeah and time. And sometimes refactoring-

Cris:

I need this now, not in a month, once it’s done.

Cody:

Yeah. And you have to consider time and what are you going to do in the meantime while you’re refactoring and rewriting? Because a rewrite basically means we’re going to do the whole thing again, with all the things we’ve learned so far. So sometimes that can mean a longer development cycle than the original application took. It could mean shorter depending on if you just want to iterate over it and just try and improve the areas that are troublesome and update everything else in the process. And then the thing about refactoring, which is a little bit different, like I mentioned, than rewriting, is that you kind of have to estimate how long a refactor is going to take, because sometimes at a certain point, when you just want to refactor an area of code, it may be that that area code will be so complex to refactor because of the rest of the application that you probably should have just done a rewrite in the first place.

Cody:

But yeah, the budgetary constraints on top of that are a big deal because if he wants to do either of those options or refactor or a rewrite, you got to have the money for it. Otherwise you just aren’t going to be able to do it, just like many other business goals. So yeah, the actual reliability goals and the budgetary constraints are the principle deciding factors for a refactor versus a rewrite versus just maintaining the application.

Cris:

Gotcha. So as Head of Dev Ops, you’re handling the department, you have your team with you, what kind of things are you doing as a Dev Ops team? What kind of practices are you trying to put in place with either projects that we are starting from scratch or practices that you’re trying to introduce when someone brings us a legacy project? What are you trying to do to help keep things flowing in a proper manner so we’re not having to deal with these rewrites and refactors?

Cody:

Well first off, all of the Dev Ops practices. Because that’s…End film.

Cris:

And cut. Yeah exactly.

Cody:

But no, that’s the goal of what Dev Ops as a central ideology is, is to improve maintainability and reliability at the same time. A lot of the times, what does that mean in reality?

Cris:

Yeah practically what does that look like?

Cody:

That usually means going into any situation where you’re going to be writing anything with an application, whether it’s something that’s legacy versus not is going design first. And that means both in the idea of software design first. Plan out what you’re going to do before you do it, but also even UI and UX design. Because let’s say, if you wrote the code first, and then you designed the UI for that code and you just kind of mesh them together at the end, chances are they’re not going to quite meet up. It’s like digging two tunnels at the same time and then trying to meet in the middle of a mountain.

Cris:

Get real lucky maybe, but it’s tough.

Cody:

Although I’m sure there’s some civil engineers out there like “We do that all the time.”

Cris:

That’s literally what my job is.

Cody:

Yeah. But as a metaphor, it’s difficult. And because of that, if you’re not quite aligned when you finally mesh the two together, a lot of times you’re going to end up refactoring some stuff anyway, and then unplanned refactoring basically is just as bad as an unmaintainable code base cause you’re just basically cowboy coding at that point. You’re just fixing whatever needs fixing, not according to a plan. And that’s the thing is we’re always very plan heavy. Design first as mentioned. So that’s the principal area that I think is the most important thing that Dev Ops practices have to offer in terms of avoiding a refactor and rewrite is simply planning out the application before it actually gets executed upon. And that’s of course what we would like to call roadmapping here.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday, where Cody and Cris were talking all about the differences between rewriting and refactoring, when you want to start having that conversation about a legacy app, of if you even want to do either one of those things, and how implementation of Dev Ops really helps you avoid that problem to begin with.

Alexandra:

If you have any questions about what they talked about today, go ahead and leave those in the comment section down below. And don’t forget to check out the description box down below. We have a ton of really helpful links for you guys, including a link to our free custom software guide that just kind of gives you some tips and tricks and walks you through the process of planning out your own app idea. Now, if you feel like you’re ready to get started on maybe developing that app, or even just seeing if Bixly might be the right fit for you, check out our website, Bixly.com. Right at the top of the homepage, there’s a button that says “Get My Roadmap”, and what that allows you to do is actually set up a free 60 minute meeting in consultation with Cris himself. He’ll give you all of his insight and feedback on your app idea. Maybe even some estimates and just seeing if we’re the right fit for you. Until next time, this has been an episode of Bixly Tech Tuesday.