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.