I’m currently working on a project that I inherited from a previous team in which I’m working on improving the code quality. The details aren’t terribly important, but here’s what you need to know to have enough context for this post:

  • I didn’t design the application, but the client wants to keep the existing design and feature set
  • The budget only allows for improvements agreed upon during the planning phase – nothing more
  • The initial codebase was developed by someone else that opted to do things in a less elegant way

As far as the last point is concerned, “less elegant” could be chalked up to laziness, or it could be chalked up to ignorance.

When possible, I try to believe the best rather than assume the worst, so I’ve opted to go with the fact that the team was under a deadline to ship rather than to build an elegant solution.

That said, I think that all developers have found themselves in this position: We’ve inherited – or contributed – to some codebase, looked around, and said:

I wouldn’t have done it that way.

Often times, the implication is that our way is a better way than the way it’s currently done. In some cases, that’s right, but if developers often think this and another developer wrote said code, where does that lead?

Anyway, this is not the first time I’ve found myself in this position, and it certainly won’t be the last, but it seemed like something worth discussing if for no other reason to share my thoughts on it.

First, I think one of the most important things for developers to learn is this:

Your way is not always the right way, but it may be the better way.

I think it’s part of the developer-maturity process. Throughout school and my career, I’ve met a number of developers who are far more concerned with finding the right way to do something rather than a right way to do something.

It’s not a math problem. That is, there’s usually not a single solution – there’s a variety of solutions that work, some of which are more optimal than others, and those are the ones that we should be pursuing.

So what happens when we’re faced with a project that doesn’t allow us to completely overhaul the codebase? Here are three thoughts on how I work on improving code quality in existing projects.

1. Recognize That We Can’t Fix It

You Can't Fix It

Improve what already exists

Honestly, this isn’t completely true. Time and budget permitting, we may have the ability to completely refactor, improve, and practically rebuild the codebase.

But the majority of the time, this isn’t the case.

Instead, I think that it’s important to realize that whatever we’re faced with isn’t necessarily our job to fix. Perhaps we’ve been contracted to add a new set of features, improve one part of the design, or tweak something that already exists.

In that case, I’d argue that our primary responsibility is to do the best job possible in the area in which we’re working. It’s tough, though, right?

I think programmers are naturally inclined to want to improve areas that aren’t necessarily our responsibility.

2. Refactor As Much As We Can

Diamond in the Rough

Create a diamond in the rough

As we’re working through your project – be it adding a new feature, tweaking an existing settings, or something similar – I think that it’s okay to refactor as much as we can within the time permitted.

But there’s a caveat to this: We don’t always know what our changes may to do to the rest of the application.

Specifically, refactoring a function may appear to work in the short term, but what if we missed one of the dependencies while doing so? We’ve then broken something that was working with the intent to improve something. It back fires.

Whenever I refactor, there are two rules of thumb that I try to follow:

  • Refactor the code thatI write
  • I only refactor something if I’m 100% sure of the consequences.

Nine times out of then, that second rule serves as a guardrail preventing me from messing with something that may end up breaking an existing feature.

3. Leave It Better Than We Found It

Before and After

Aim for something like this

When you begin tweaking, introducing, or modifying and existing codebase, you may not be able to improve the overall application, but you do have the ability to leave it better than you found it.

See, I think that if an application is poorly coded, I believe we can rationalize writing bad code ourselves under the idea that it was bad to begin with, so who would who ever know?

But I call lack of developer integrity on that.

Instead, the very least we can do is attempt to leave behind somewhat of higher quality that what we found when we arrived. Perhaps our area of code will follow some sort of coding standard, or file organizational scheme. Maybe it will include comments, documentation, or will implement some form of design pattern.

Whatever it is, there will be a stark difference between what we write and was previously existed, and future developers will take note.

Besides, that helps to define a level of developer integrity. If nothing else, aim for it.

I’m sure there’s more to it than this, so feel free to share your approach in the comments.