Xkcd probably ties for second with Penny Arcade in my list of favorite webcomics (the #1 spot goes to Questionable Content, despite my unending annoyance at the fact that the author has yet to have Marten hook up with Faye). For those not familiar, Xkcd tends to focus on popular science, algorithms, coding, and other similarly geeky topics. Not long ago the following gem was published:
Now I’ve spent enough time in the tech industry to recognize that on many occasions this comic is as accurate as it is humorous. When working on any project of substance it is far more often the case that the requirements are a moving target, a living and breathing entity being pushed and pulled and cajoled and mutated by any number of external influencers, from the UX department who have just completed Yet Another Usability Study™ and concluded that The Entire UI Needs To Be Redone™ to the lead architect who wants to restructure the internals to use his new design that will Solve All Problems Forever™ to the engineers working deep in the code who have just discovered that The Feature You Want Is Not Feasible™.
The pragmatic coder is left with two basic options, often punctuated with an Unreasonable Deadline™; either code fast and try to meet the requirements before they change, or do things correctly and hope the requirements don’t change too much before you get there. More experienced coders know how to code fast better and/or how to code well faster, but the basic options remain the same, and often you will still be faced with scenarios where you’ve coded yourself into a corner, or had the requirements change before you got there.
So what to do in these situations? As much as I appreciate the tongue-in-cheek humor of the original comic, I believe there is a simple solution to the problem that it poses. Namely, refactoring. Refactoring fits in like so:
Refactoring is the art of transforming What I Have™ into What I Need™ and getting from I Finally Made It Work™ to I Can Make It Work Anywhere™ without having to throw away and rewrite 90% of your code, and the ability to refactor effectively is often the only thing truly separating good engineers from poor ones.
This is a subject that should be covered in any serious computer-science curriculum, yet unfortunately the first experience many engineers will have with refactoring will be when their first employer asks them to turn That Really Old Codebase That Nobody Understands™ into The Next Big Thing™. At this point one of two things will happen. Either they will refactor That Really Old Codebase That Nobody Understands™ into Something I Can Work With™, or they will decide that We Have to Rebuild It From Scratch™. Either approach can take a long time, but one is guaranteed to be far more disruptive and risk-prone than the other.
Embrace refactoring. It won’t save your life, lead you to salvation, or guarantee you eternal paradise, but it just might save your project, or even your company, from failure.