Matt Woodward has a keen mind for technical topics. I’ve enjoyed his work for a variety of years on a variety of topics such as Mach-II, The CF Weekly, Conference Presentations, CHUG and others. Today, Matt wrote a thought provoking piece about a situation that happened on his team. The piece is entitled Avoid Refactoring Yourself Into A Corner
Apart from being well written, this article explains how a change in the stakeholders precipitated a supposed change in requirements. Implementing this requirements change would have been lengthy and time-prohibitive. Through the benefit of a sharp team and open dialogue, Matt’s crew was able to forgo a long and drawn out refactoring.
Refactoring is a great way to make incremental improvements to a code base, or to deal with shifting requirements. Often refactoring requires a deep understanding of many ongoing processes and the dependancies between each. All of this complication can obscure possible solutions. As Matt points out:
It’s easy when you’re neck deep in an application to have your thinking get a bit rigid and not be able to see the numerous other ways in which the problem you’re facing might be solved. So you start going down straight-line path you see in front of you and figuring out ways to tweak what’s already there to handle a new requirement that may well be the antithesis of what your domain model was originally designed to address.
I challenge you to give Avoid Refactoring Yourself Into A Corner a read and then have an honest think about similar situations you’ve been in before.