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.
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.
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.
Refactoring is a dish best served warm. It only works as home cooking, where the cooks eat their own cooking hot off the stove. Start with a few beneficial small things to make the team's life easier, then once the team is sold on the idea, go on to more daring ones. Best done with automated tests and continuous integration.
At my last position, we were told that it was expected to refactor every time we updated any module. However, we had no list of things that needed to be refactored, no real team programming patterns or standards, and we were rewarded almost solely on implementing new features quickly. Sure, someone could refactor code and make it easier for others in the future, but there was never a reward for that, and often there were questions about why it took extra time to implement.
Without team standards, a list of things to refactor (if available), and rewards or recognition for actually making cleaner, more maintainable code, most developers will do what gets them recognition, pay raises, and such. The thing that often gets recognized is implementing new, visible features.
Refactoring is step 2 in this process. Sometimes I write something and I already know a great architecture for it, so that code is, in a sense, "prefactored". But most of the time I'm solving a relatively new problem and have no idea what I'm doing or how I'll end up coding it. At these times, the "compulsive architect" is at a disadvantage because, in his quest for building things right the first time, he will stare at the IDE and have trouble getting started. That's why I force myself to take the architect hat off and give myself permission to create ugly hacks in step 1.
This same concept applies when I'm adding new functionality to an existing code base. I have to turn off the "but my beautiful architecture!" side of myself long enough to get something working, then remember to turn it on again so my code doesn't turn into a giant ball of mud.
Everyone has their ways of working, but I consider this an important principle of software development. In it, I think, is the reason that "scheduled refactoring" so often fails or, at best, hinders everyone on the team. Programming is more akin to painting or sculpting than to building roads and bridges. It is a deeply personal endeavor and the emotional and practical problems of combining the work of multiple creators into a cohesive whole is a task that should not be undertaken lightly. Ignoring this truth gets you situations like trying to gather nine women to make a baby in a month. It also explains why independent refactoring is often doomed to failure:
- There are practical problems with having the entire code base in such a state of flux. Even with our much-improved merging situation vis-a-vis git, developers will dread merging their work into the radically refactoring branch. This adds a braking effect to the cognitive inertia we try so hard to maintain.
- Refactoring teams dissolve code ownership. The resulting more homogenous code base may tick all the right boxes for management and architects, but it can also (subliminally if not explicitly) tick off the original developers.
- Refactoring is a natural and integrated part of EVERY developers job, one that is best performed holisticaly in context with the rest of his or her tasks. Relegating it to a separate team or denanding that it he performed at a certain calendar time is antithetical to the natural flow of most hackers. Purposefully leaving things ugly so that there's stuff to be refactored later is a soul-sapping side effect of the "refactoring team", especially when the results are metricized.
- The best refactoring happens spontaneously: either an individual developer will say "ok I can't stand how much this sucks one second longer" or a couple of devs will be chatting in the hall and remark how lame the interface between x and y is. These kinds of things usually result in positive refactorings because they stem from an aesthetic desire for beauty combined with a pragmatic quest to remove roadblocks in the code. It's hard to schedule and dictate these "moments of higher truth" in an application's life.
It takes a good team and talented developers to make this all work. It also takes management that understands the need to give developers time to clean up and polish, and that such effort does not, in fact, make the project slower. But then again, a large reason why such an emphasis had been placed on explicit refactoring in recent years is to counteract the tendency for management to throw large numbers of cheap developers at a problem rather than a small group of quality ones. The inevitable mess that results is, sadly but predictably, a titanic for which even the most disciplined refactoring efforts only serve as pumps to prolong the inevitable foundering.
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.