Hacker News Reader

Comment by mmahemoff | Hacker News Reader

Part of the criticism is about having a separate refactoring team, which is an awful idea for the reasons mentioned. It doesn't invalidate the value of a "refactoring task" for the core team though.

I think it's sometimes a good practice to declare every 2nd Friday (for example) a refactoring day. I realise that's the Anti-Lean, but it has merits for a larger team where things get complex and it's important to keep talented people happy, There's value in just saying "take some time out to weed out the things that annoy you most" and of course still taking into account which refactorings would be most strategic given future plans.

View on HN

Refactoring as a separate task is a bad idea from good intentions. If you blow your schedule on some other higher-priority tasks (i.e., directly business-relevant), guess which task is the top candidate for deferral? Speaking from experience.

Paying down technical debt is business-relevant, but not directly relevant. That means things on fire or new contracts or whatever will always supersede things of indirect benefit. Under sufficient load, this effectively means no refactoring, because people are then trained to wait until they are tasked with "the refactoring task".

What has served me well is following Fowler's advice, which is repeated in this article. Refactor when you want to do something else. I would add: Prefer modifying only code that will be QA tested anyway, so you don't explode your testing surface area. Do it as part of a directly business-relevant task. Build it into your estimates.

How would you approach, say, encapsulating a global static field that's used in every single file of a legacy application using Fowler's advise?

I wouldn't, unless it's hampering you from doing something else OR you've got a full regression test coming up (for example, during a major version increment).

Yeah, when I read this I thought "duh"; having an entire other team of developers come in and totally change a codebase and not communicate what/why they changed to another team that's frequently working on that codebase sounds like a recipe for disaster. I can't imagine why anyone with even a small amount of development experience would think that would be a good idea.

Reply on news.ycombinator.com