Know when to refine, when to refactor and when to refrain
Chris J Davis in Lessons for the Newly Minted:
As you can clearly see, when you have tight deadlines, and mountains of work, refactoring existing code that works is highly unadvisable. As a developer you must make strategic decisions about where your time is spent, and this must be informed and balanced by the needs of the company. Should you strive to craft breathtakingly beautiful code? Yes, but not at the expense of the overall velocity of your development schedule. Sometimes good enough is beautiful.
Amen to that.
January 11th, 2010 at 12:08 pm
I could not agree less.
“refactoring existing code that works is highly unadvisable” – if you need to refactor it, it doesn’t work. I’m sick of people portraying good code as a pipe dream, and tolerating rubbish because it “works”. The quality of code is the most fundamental problem in our industry and until we start taking it seriously, we’ll never solve the big problems. It’s important and you need to fight for it.
January 11th, 2010 at 12:29 pm
It’s not about never refactoring code that doesn’t work, it’s about focussing on what will give you the most benefit, rather than what happens to be right in front of you now. The lean philosophy really gets this quite right. You can’t just optimise one tiny bit of the business and expect to have any real effect, you need to think globally about the business and focus on the key bottleneck, solve it then find the new bottleneck.
“existing code that works” doesn’t always mean “rubbish” either – it means good enough. Literally, it is good enough – it doesn’t require improvements and doing them will gain you nothing. It is achieving all it’s current objectives – if new objectives come along you can still do that same refactoring work if it’s required. Remember “You Ain’t Gonna Need It”? Good enough does not mean it’s barely working, it means it’s working well and is maintainable. You should move on and focus on the areas of code that aren’t yet good enough instead.
January 11th, 2010 at 3:41 pm
I do believe in ruthless refactoring of the code you need to work with, but don’t believe in refactoring for refactoring sake, so I agree on the OA depending on the context.
If you have to modify some code and you need to refactor it to make the change easier, then you decide between refactoring or writting down a technical debt (that should be paid in the short term, tech debt has a high APR).
If, while working on a task, you’re browsing the code and find a place where a refactoring is called for (ie, a lot of code duplication) but is not code that would have been modified in by current task, then it should not be refactored. A task must be scheduled to do it later, or a TODO must be put in place for next developer that works on that code.
I do prefer the TODO method. If when estimating the developer finds a lot of TODOs (developers check the code before estimating, right?) then it can factor in the work needed to “clean” the code. That leads to better planning and better code.
January 11th, 2010 at 4:35 pm
Rafael,
Yep, that’s the kind of balance that needs to be found – improving code where it’s needed combined with actually being able to get stuff done.