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.


Join the conversation! 8 Comments

  1. Great points! I often find myself in this situation with my own code. In our line of work, everything is changing so rapidly that constant learning is a must. I regularly look back on code that I wrote 6 months ago and wish I would’ve done it differently. In these cases, because of time constraints, I usually fall under #2 (refactor as much as I can) as I’m a bit more familiar with what effect my changes will have on other parts of the project.

    • Yeah – even doing so with my own code is tough. One of the worst things is coming back to work on a project I did a year or so ago and seeing how bad it really was.

      On top of that, there’s knowing that I’ll probably do the same for whatever I’m working on now.

      At any rate, you’re right – refactoring as much as you can with your own stuff is infinitely easier than doing so for code someone else wrote.

  2. Funny enough, I find myself doing this with my OWN code. Things I wrote even 6 months ago have code structure I wouldn’t touch now. Being that I’ve released a handful of plugins in the repository, it gives me the opportunity to go back and re-factor things as needed, whether it’s due to a bug found by someone or just scratching my own itch.

    • I see the same thing all the time. I Spent an hour or two just yesterday going back through one of my older plugins in order to fix some security problems. In doing so, I was constantly saying to my self: “why on earth did I do it this way?!”. I’ve come to realize that this happens to everyone, or at least those that actively work on improving their code quality.

      • I’ve come to realize that this happens to everyone, or at least those that actively work on improving their code quality.

        Exactly – and I think those are always the ones who care more about “just getting it working.” There’s working, and there’s working well.

    • Yep – same here. I think it’s the nature of the beat, really.

      There are a number of plugins that I’ve released where I’ve gone back and simply refactored them without adding any new functionality simply because I disliked what I had our there.

  3. The phrase “developer integrity” is my favorite part of this post.

    Thank you for being the resounding voice, especially in the WordPress space, to continue to code to a higher standard.

    Not just because you can, but because you should.

Leave a Reply