In Part I, I mentioned one of the dilemmas voiced by developers who want to inject some beautiful code in their day-to-day activities:

“I am maintaining a steaming pile of legacy code that I have inherited. I can barely keep the code base working – sort of. I would love to write some beautiful code, but have no time to think about beauty as long as I am saddled with this ugly code base.”

This is a very common situation. Most developers spend most of their time maintaining/enhancing code that they did not write and, more often than not, that code base is not just ugly, but coyote ugly [1].

So, what’s a developer to do when stuck with code so bad that it should come with an “abandon all hope ye who enter here” warning? There are three basic options (besides the extreme the coyote option – which I don’t want to offer for legal liability reasons):

Option 1: Run for the hills (i.e., ask, beg, bribe for another assignment – or quit).

Option 2: Accept the job with resignation. Abandon hope and prepare yourself for a coding life of quiet desperation highlighted by moments of sheer panic. Help to prove that Thomas Jefferson was spot-on when he said: "Mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed.”

Option 3: Accept the job as a challenge. Accept that the code base is ugly; it’s OK – therapeutic even – to make fun of it and of the careless, incompetent, so-called-programmers who developed it. Accept the fact that you cannot single-handedly turn a huge steaming pile of legacy code into a thing of beauty. But be determined and committed to reject and eliminate ugliness in the bits of code that you do touch. In other words: scorn globally, act locally.

The first option is probably the smartest one but, with so much crappy legacy code out there, you might have a hard time finding a suitable job. The second one is the easiest, but is not something that I would ever consider or recommend. The third option is the hardest to embrace, at least at the beginning, but the noblest and the one I want to talk about.

Since it’s unlikely that you will have the option to make sweeping design or architectural changes, the key to success in working with a pile of ugly code is to focus on small improvements. When you run into an ugly bit of code that you can or must change, make a conscious decision to make it more beautiful.

This, of course, raises the issue of what “more beautiful” means. If you have read Beautiful Code, you have probably realized that each author had a personal definition, or bias, for what constitutes beauty. The good news is that since you are the one working on the code, you can apply your own criteria for beauty.

Here are just a few of the many localized actions that you can practice – assuming you agree with my criteria for beauty:

• Write tests for a particular piece of code before you change it. A test suite is a beautiful thing to have and it will give you a safety net as you make those changes. If you are working with legacy code, you should become an expert at writing characterization tests*[2].
• Refactor to reduce complexity and improve testability. Method extraction is my favorite refactoring; it’s fast, safe (especially if you have tests), and easy to revert if needed. In my book, any method with a cyclomatic complexity of 8 or more is a candidate for refactoring.
• Rename cryptic or ambiguous identifiers. This is a pet peeve of mine. In this age of cheap computing resources there’s no excuse for using a variable name like “ac” instead of “areaCode”.
• Delete. If you can identify dead, useless, duplicate, or obsolete code, get rid of it.

Sounds like easy and obvious advice, doesn’t it? Well, it might be easy and obvious but, unfortunately, it’s rarely practiced. Otherwise I would not have bothered to write this. The reality is that, in most cases, ugly code becomes uglier as it’s maintained or enhanced. As a matter of fact, a lot of code starts out pretty nice and clean (both in design and implementation) and degrades as time goes on. It happens gradually. It’s done innocently. In the short term, adding yet another if statement inside a nested for loop is faster and easier than taking some time to think of a way to refactor the code to reduce complexity; it does not look like a really bad thing. But over time, these actions add up.

Taking time to write a little test, perform a simple refactoring, or rename one variable, does not sound like much; but it represents a huge – HUGE – change in attitude and a rare and courageous stance toward legacy code. It means that you don’t accept the inevitable slide from ugly code to uglier code.

Reducing ugliness in legacy code one method at a time, may not be as glamorous as creating a few lines of beautiful code suitable for framing, but I would argue that it might be just as important and a far nobler thing to do – and you’ll never run short of opportunities to practice it.

Alberto

[1] Coyote ugly: code so ugly that some developers might prefer to chew their fingers off rather than work on it – much in the same way that a coyote captured in a jaw trap will chew off its own leg to escape certain death. Sorry if this is a bit too graphic.

[2] Characterization tests: a term coined by Michael Feathers in his excellent book Working Effectively With Legacy Code to describe tests that capture not the specified, but the actual, behavior of a piece of code. See: Characterization Test and Working Effectively With Characterization Tests