« The Puritan's Olympics | Main | Preaching to the Inconvertible? »
September 12, 2004
Refactoring for Fun and Profit
I write this on the eve of what could be an interesting week for my project team: the client has thoughtfully decided to give us "a week off" to spend on the larger scale refactorings our codebase is becoming increasingly in need of. In other words, we have a one week iteration with no business stories scheduled, only technical ones. I'm not sure what the principal reason for this show of benevolence is, but I know our development velocity has been creating a bit of a backlog downstream in the post-iteration/pre-release testing cycle and the team is missing some key people, so we're effectively taking the foot off the pedal and putting the car in neutral until next week.
Whilst the perfectionist in me is grateful for the opportunity to work on some of the larger scale refactors (or restructures, as they should probably be called if you go by the Fowler definition), I see this precedent as a double-edged sword...
On one hand, we have a poorly performing test suite that is in dire need of considerable attention and a week's worth of TLC with a liberal dose of more sensible testing strategies should see us make a big dent in the execution time of the suite. My gut feel tells me that we should be able to reduce the running time (currently in the order of 45 minutes) in half with a handful of big win modifications (e.g., using an in-memory DB, mocking out several external dependencies, etc) which will leave us in a much better position to tackle the smaller gain items as part of normal story development.
As a counterpoint, I'm worrried about the perception of the development team's activities in the larger project/company context. Given that the central concept of refactoring is foreign to most people outside of development, will we be held to ransom the next time we require such work be done? I suspect this entire scenario is a smell that the team has not been communicating the constant need for refactoring and the associated risks of not giving this aspect of development sufficient resources. Time will tell.
Expectation management is an enormous challenge on an Agile project with a client unfamiliar with such techniques. However, it's far less pain in the long run to create the correct mindset from the very beginning than it is to try to correct things midstream once project cultural and operating norms have been established. Drastic changes of this nature can be met with attitudes ranging from frustration and confusion to open suspicion. Even if a particular practice is not implemented in a project immediately for whatever reason, it is vital that it be kept on the radar to reduce the sticker shock resulting from it's eventual introduction.
Posted by Andy Marks at September 12, 2004 06:43 PM
Comments
I wonder in some cases whether I want to use the "refactoring iteration" to instead demonstrate how a normal iteration should work such that "refactoring iterations" will not be needed.
Posted by: Jason Yip at September 13, 2004 08:37 AM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)