Tuesday, September 11, 2007

In computer programming there is an activity known as "refactoring". It's when you take existing code and you reorganize it so that sections are more logically grouped, it has less duplication, there are fewer unneeded parts, and it's just plain easier to read. This is similar to the "factoring" we used to do in algebra where we'd take some mathematical expression and break it down into its components.

Of course in computer science, you don't factor, you REfactor, which as near as I can tell, is some kind of ironic name. If you're REfactoring, that implies that the code had already been factored into logical parts in the first place. Judging by all the code that I've ever been asked to refactor, if it was factored in the first place, it was done so by skittish chihuahuas, and not the smart kind either.

Actually, that's not entirely true. My team at work inherited a program that has perplexed us for the last year and a half. We try to add the simplest features to it and we're constantly stymied by its byzantine organization. I honestly cannot tell if it was written by idiots or geniuses. Were they chihuahuas, yipping and yelping their way into 1000-line methods, or savants who did not feel the need to structure the code in traditional hu-man ways? Only the ancients know for sure.

At separate times each member of our team has found themselves with a free afternoon and has tried to untangle small parts of the program. We'd start following a thread, carefully pulling it and saying positive affirmations, and after a few hours we'd find ourselves convulsing and completely wrapped in spaghetti. We'd apologize to the software gods for our hubris, remove our changes, and slowly back away from the keyboard.

Recently, however, thanks to the methodical deliberating by our new German overlords and a lucky confluence of scheduling holes, our team has found ourselves with a couple of weeks to fill as we see fit. Although I unsuccessfully lobbied for a thorough investigation of this alleged Internet porn-o-graphy I've heard so much about, instead it was decided that we should attack the software that had vexed us for 18 months and refactor it into submission. Since the program code was bigger than any one of our brains, my boss assigned two of us to the task.

So, for the last couple weeks, I've spent the entire workday on the phone with a coworker, jointly analyzing code on a software archaeological dig. I can say, with a surprising amount of sincerity, that this has been the most rewarding thing I've done at work in a long time.

In the past, we'd try to add some tiny thing to the code, sort of like adding a bell to the handlebars of a tricycle, and we'd get tripped up by something totally unexpected, like for example, finding a bunch of snakes slithering around the handlebars.

"SNAKES!" we'd scream, but we'd fear removing the snakes because they'd have a sign right next to them saying something like "Don't remove these, or the tricycle will crash!"

What? Crap. Ok.

And we'd leave the snakes in place, carefully placing the bell on the back wheel, as far away as possible from the snakes. And then our customers would ride away on the tricycle, denting and dinging the bell each time the back wheel made a rotation. And we'd mark off that to-do item on the big spreadsheet. Done.

Not this time though! This time we're actually staring at the tricycle and the maintenance history long enough to say, "Ohhhh! They didn't mean to put snakes on this trike. They meant to add BRAKES!" So we're finally removing the snakes after 18 months of being repeatedly bitten. How the chihuahuas got the snakes in there in the first place is still a mystery, but, whatever.

As it turns out, removing parts of a program is pretty much the most satisfying thing one can do to software, short of deleting it entirely. Imagine staring at your car engine for a week, and eventually saying, "Oh, this really hot part in the middle is unnecessary" and being right. It restores your faith in the universe.

Now all I need to do is refactor this blog post. Maybe next year.

9 comments:

Anonymous said...

refactoring as popularly described tends to not take into account the original programming approach.

stereotypically, these might be categorized as the excessively defensive coder, the hacker, the bleeding-edge implementor, the all-night coder, the i've-got-three-jobs-and-two-girlfriends detailer (er, lack of), ever-present there's-a-deadline-works-for-me-living-in -a-closet engineer. let's not forget layers-and-design-pattern-cause-thats-what-Sun-says implementor.

discovery of the pattern to resolve the patterned anti-pattern pattern can often hinge on the pyschology of the originating speedy-typer combined the proverbial layering on-top-of, discernable intuitively via svn blame and log.

Anonymous said...

typetypetype, type, type, typetype.

(* hmmm.... this code sucks! who wrote this? *)

typetype, type...

(* ooooh, omg, I wrote this! *)

Mike said...

MMH, getting into the psychology of the original coder is a dangerous task, lest you get sucked into the mental disorder that created the software morass in the first place.

As for your (I think it was yours) suggestion that sometimes perhaps the refactorer was also the original factorer, no comment. :)

E said...

Can you please come work at my company?

Because the chihuahuas left not only snakes on the handlebars, but giant manic-depressive polar bears who ride the tricycle right over top of the hapless user...

(One of the main programs we use has a big "COPYRIGHT 1986" proudly displayed on the login page)

Mike said...

Ms E (may I call you Ms E?), sure, I'll come work for your company. Please confirm that it's ok that I'll be working Pacific time and I'll be working from home. Also, I need to be paid a lot. Please send the appropriate forms.

As for your 1986 program, what is it? Zork?

tinyhands said...

This post needs more metaphors.

Mike said...

Tiny, believe me, it HAD more metaphors, but they got excised when I removed the actual code examples from the post.

Will said...

Wow, refactoring and pair programming. You should never stop : )

Mike said...

Will, sadly, I think we're winding down this exercise. And, after weeks of making the code better, I'll probably be moving onto a totally different project. Oh well.