

Independent Refactoring is Irresponsible - Digit-Al
http://www.thekua.com/atwork/2013/01/independent-refactoring-is-irresponsible/

======
mmahemoff
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.

~~~
mratzloff
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.

~~~
gambler
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?

~~~
mratzloff
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).

------
breckinloggins
When I develop things I:

\- Make it work (but good lord is it ugly)

\- Make it pretty

\- Make it fast (if necessary)

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.

------
stcredzero
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.

------
JCraig
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.

------
lutusp
A quote: "Both Michael Feathers and Rachel Davies recently recently [sic]
wrote about ..."

Does "recently recently" mean very recently? Second question: what happened to
proofreading?

~~~
Snoptic
It means it is a little earlier than recently

