I will never forget my first real job. While still in junior college trying to earn my Associate’s degree, I was hired on as a co-op intern at a local engineering facility. One of my tasks was to document a report generator written in C++. Little did I know what kind of treat I was in for.
I cracked open the solution file in my Visual Studio IDE and hunted around the code for a short time. There wasn’t much to the project – typical resource and header files you would see in a legacy MFC-based application. The app had a single application window that contained the entire logic for the application. I was immediately concerned, considering how long the former developer had worked on this and how important the generated reports were.
When I opened the code file containing the logic, my mouth dropped to the floor. The file was thousands upon thousands of lines of code in length. What made matters even more jaw-dropping was the fact that 99% of this code was in a single function. I did what any junior developer would do.
I printed it out on our company’s state of the art laser printer. All 200 pages of it.
I dropped the document on my boss’s desk. Then I proceeded to highlight the code on the first page that would be duplicated with very few modifications on the remaining 199 pages. Duplication, duplication, duplication.
I have never seen messier code, and I’ve been working in this industry for 17 years. As unfortunate as it was, however, it showed me something incredibly important. You must attack and defeat crappy code like it’s the plague. I would later learn that the industry’s standard term for this was “refactoring.”
What Are the Benefits of Refactoring?
I believe that refactoring is one of the most basic and essential development skills that a developer needs. In my many years of software development and architecture, I have found the most successful developers have been those that constantly refactor their code. But why?
1. Refactoring increases the lifetime of the application.
The second law of thermodynamics states that an isolated system can only become more disorderly over time. Although I understand this law to be speaking in terms of energy loss, this notion translates well into the software world. Martin Fowler, in his book Refactoring, states that the design of a program is in a constant state of decay. Failure to continue to refactor code will ultimately lead to its death. I consider proper refactoring techniques the lifeblood of a good software application. Refactoring can inject new life into your program.
2. Refactoring decreases technical debt in the application.
Technical debt in software works very much like financial debt. You can borrow with funds that you don’t have, but you’ll always have to pay it back. We borrow when we write code that is messy, but it works. The problem is that it’s hard to determine when you’re getting close to the tipping point of not being able to pay the minimum payment. Refactoring is Dave Ramsey’s software version of the debt snowball plan.
3. Refactoring makes the code easier to read and understand.
Code that is easier to read and understand translates to code that is more maintainable. It is easier to add new features to code that is easy to maintain.
4. Refactoring removes code duplication.
My brain can’t comprehend a 200 page-long function. When I refactored this function, it reduced the code to fit on a single letter-sized page, with Courier New 12-pt font. *mic drop*
5. Refactoring ensures consistency in code paths.
Often times, especially with larger development teams, multiple developers will be working on similar features. These features may be implemented in slightly different ways making way for inconsistencies in code. Refactoring can combine these divergent code paths and totally eliminate the inconsistency.
I believe that refactoring is more than a task; it’s a way of life. It’s a development culture. As Martin Fowler says in his book, you don’t set aside time in each sprint to refactor. You refactor as part of new feature development, or as part of fixing a bug. When it’s in your blood, you will constantly reap the benefits of refactoring while turning the decay process around.
What is the scariest code base that you’ve ever been exposed to?
