Skip to content

Refactoring in the future is not an excuse for messy code in the right-now

September 23, 2009

– “Hey, what’s up with this messy code here?”
– “Oh yeah, don’t look at that, I’ll refactor that soon.”

BZZZT. Wrong answer.

Your code is here to stay — at least for a while, and probably longer than you think. Accept that.
Any piece of code you write is an integral part of the codebase from the second you’ve committed it to source control; it will be used in situations you did not expect when originally writing it, and it will mutate. Because that’s what happens to code in a team-owned codebase.

It’s true: your code will never enjoy the peaceful solitude in exile you intended for it. Any other developers who might come across your messy code will change it, aligning themselves with the messy style around then. They will split it to different parts during one of their own refactorings, spreading your messiness where it’ll be hard to find and remove. And worse of all, they will mimic it, making your messiness the common rule rather than the exception that should never have been there in the first place. All because they assume that anything they find in the codebase is up to quality standards, because otherwise you wouldn’t have committed it.

See, in a team environment, we all implicitly assume that any code in the codebase belongs there until proven otherwise. We assume nobody intentionally commits a broken window and leaves it there. Let me put it this way: your teammates think you’re a responsible developer. Congratulations.

The absolute minimum you can do, if you do find yourself committing sloppy code thinking “I really should refactor this soon”, is to break this assumption by clearly labeling your code as bad. Boldly declare your sloppiness in the comments. Make sure no one could ever mistake this code for good, usable code. Let people know you did a half-assed job, and that they shouldn’t assume this is the correct way to do things. The quality of the codebase comes before your personal dignity.

What’s that? You want to keep your dignity? Right. Well, luckily there’s another option: don’t commit sloppy code in the first place.

Alright, I know what you’re thinking, but stay with me here. I’m not saying everything you write must be flawless. Far from it. Your code doesn’t have to have the most elegant design or the most efficient algorithm, but once you’ve decided on a particular way to implement something, do it in the best way you can, according to your own personal quality standards (and those of your team, if they happen to be different from your own).
Extract common functionality where applicable. Separate concerns. Write automated tests for your code. Maintain naming and styling conventions, for crying out loud. These things aren’t “a nice finish” applied only to your best code. They’re the bare essentials of your work, even — and particularly — when you know it’s flawed. If anything, they will make your future refactoring easier (what do you know, maybe someone else will even do it for you when they see that piece of code, instead of going “WTF?!”). Even if they won’t, at least you’ve gotten into the habit of writing quality code all the time.

Developers around you assume they can count on you to keep the codebase nice and clean. Don’t let them down.


From → software

    • Avish permalink

      Excatly. Uncle Bob expresses it slightly differently and perhaps more clearly, but it seems like we’re making the same point (this must be a great honor for him!).

      It’s also interesting to note that we both independently chose the term “mess” for that-thing-which-isn’t-professional-code. I may have something further to say about this in a different post. Maybe.

  1. Ninjarabbi permalink

    Wouldn’t a simple “no review – no commit” policy solve this?

    Management to the rescue!

    • Avish permalink

      In principle — yes, it would. It’s not even a management issue, since in most healthy teams developers would naturally agree to a good policy if it was suggested from within.

      The problem with this is that it doesn’t scale well. Ultimately, people are going to work alone and commit alone. The problem gets even worse if there’s more than one person committing mess (that way they can “review” each other).

      But the issue here isn’t one of discipline, it’s an issue of perception. Policies are backed by agreement. In this case, before starting a policy like one you suggested we first have to agree about what’s good code and what’s bad code. This post is supposed to be an argument (or a reminder) for a specific behavior to be considered “bad”, before we move on to “what can we do about it”.

      • Tomata permalink

        But why go all theoretical about it? Moving the problem to the philosophic “What is good or bad code?” realm just makes it harder to solve. You can always start with the easy-to-implement tactic and get creative if it fails.

  2. Avish permalink

    @Tomata, @Ninjarabbi — For some reason you both seem to have the impression I’m trying to solve a specific problem here. I’m not. I’m trying to make a point about how to develop software better in a team environment. This isn’t a “what to do if someone on your team is writing crappy code” post; it’s a “how not to write crappy code” post.

    Even if I did want to just “solve the problem”, getting rid of the symptom (e.g. by requiring developers to undergo code review before committing) won’t help the people involved improve as individual developers or as a team — which is what we’re all after.

    In fact, if you expect the “messy developer” to learn anything from the code review (which I assume you do, because otherwise you’re wasting your time being a cop instead of a teacher), the reviewer would have to explain to them why that kind of code is bad, and what they can do about it — which is exactly what the post is about.

    So in my opinion, “going all theoretical about it” is the only *real* way of handling this so-called “problem” — although in the same vein, I prefer not to look at it as a problem that needs solving, but rather as an opportunity for any developer (myself included of course) to improve the quality of their work.

Say Something

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s