Ep. 26 – Sufficient Design, Death of Refactoring, and Certifications

Allen and Mike get together on Memorial Day to discuss a few articles from around the Agile web. The tour touches on the “Sufficient Design” discussion, whether the term “refactoring” is already dead, and whether certifications are good, irrelevant, evil, or all of the above.


One thought on “Ep. 26 – Sufficient Design, Death of Refactoring, and Certifications

  1. I’m coming quite late to the game, but have been catching up on all your podcasts. I’ve been enjoying them, but this one left me disagreeing with your conclusions. First, you discussed the quality vs. speed tradeoffs, and mentioned that you should avoid low quality, slow speed (duh!). But it turns out that there’s a really easy way to end up there.

    Take the low quality, high speed shortcut too often, and it quickly becomes impossible to keep up the high speed. At this point, speed slows down, and as you look through the code, despair strikes. To improve the situation requires some major cleanup. Methods need to be extracted (in fact, likely whole classes need to be extracted), variables renamed, and logic needs to be cleaned up. All of this should be done without changing the behavior of the existing code, but we’re not talking a few minutes here. This is what is meant by a major refactoring. It’s how you get out of the hole of major technical debt.

    By way of example, I inherited some code with a main file that was over 8000 lines long. About 7000 of those lines were in the main method. Obviously, a lot of work had been done to minimize the size of patches over the years, so nobody ever paid attention to the overall architecture of the code. By the time I finished spending nearly 3 months trying to salvage this beast, I had the main method down to under five hundred lines, and the main file under a thousand lines. I introduced several procedural routines (without object-orientation) just to get a handle on what the program actually did. Once that had happened, I was able to start pulling out objects from the mess left behind.

    Before I did any of this, though, I put some basic functional testing in place to verify that I hadn’t broken the basic behavior. We had trouble reports dating back over three years on this product because nobody wanted to touch it. Hopefully, we’ve broken the logjam on it, but this was definitely a case where a major refactoring was an entirely appropriate term, because we changed the design (from horrible to bad, but it’s a start) without changing the external behavior.

    But when people discuss major refactorings, you also have to realize that this is a way of trying to move something of poor quality up the quality chain a little way. It’s entirely possible to spend a lot of time polishing a turd to make it shine, and that’s a trap to be wary of!

Leave a Reply

Your email address will not be published. Required fields are marked *