"refactor mercilessly"?

Jules

unread,

Aug 25, 2003, 11:55:12 PM8/25/03

to

Hi,
I'm having a bit of trouble reconciling the "you aren't gonna need it"
(YAGNI) and "refactor mercilessly" tenets of XP. I'm running through a
codebase refactoring quite... well, mercilessly! But I'm doing this because
I am soon to deploy this codebase into 2 other projects and obviously I want
to avoid forking the code. The problem is, my refactoring is now focussing
on items I _anticipate_ will cause headaches in the near future.

Yes, I'm anticipating future problems. I figure it's easier to refactor
now, than when the codebase gets bigger. I'm refactoring to make future
refactorings easier, if you will.

Is this a violation of YAGNI? Am I being silly even bothering to wonder
about this? Bear in mind that I'm not coding any new functionality, just
altering various parts of the architecture (quite dramatically in some
cases) to further abstract the apps functions.

Jules

Phlip

unread,

Aug 26, 2003, 12:17:51 AM8/26/03

to

[XPosted to the XP newsgroup; please set follows-up]

Jules wrote:

> I'm having a bit of trouble reconciling the "you aren't gonna need it"
> (YAGNI) and "refactor mercilessly" tenets of XP. I'm running through a
> codebase refactoring quite... well, mercilessly! But I'm doing this
because
> I am soon to deploy this codebase into 2 other projects and obviously I
want
> to avoid forking the code. The problem is, my refactoring is now
focussing
> on items I _anticipate_ will cause headaches in the near future.

XP does not exactly say "You are never going to need anything unless your
customer explicitely states it".

Rather, XP inverts the priorities compared to projects that fear changing
their infrastructure. You are going to need, for now, a light
infrastructure. Pretend you aren't gonna need a really heavy one, and we
might increase odds you don't.

But you ARE going to need a phat test rig, squeaky clean code, and the
ability to refactor that code mercilessly.

This means you leverage priorities. If the test rig breaks, you stop the
assembly line, and all the workers collaborate to un-break it. The test rig
is higher priority than all feature requests.

Similarily, if the code is even a tiny bit hairy, and is not lean and
expressive, this takes priority over your next feature request. Fix the
code, incrementally.

Finally, XP does not recommend "get merciless every time you refactor".

Incremental small refactors after each feature dramatically reduce the odds
the code will ever need a big refactor. But you are going to need the
ability to refactor mercilessly. New features might push the design towards
a "pop", after which the best design for a module might be completely
different.

You get the ability to refactor mercilessly by refactoring incrementally.
This tests the tests, decouples them from the code, and puts the code into a
lean design so it's always ready.

In your current situation, if your refactoring narrows, and removes code the
current codebase does not need, keep going. If you refactor to put in a
design that you anticipate will be easier for the new project, but the
design still contains minimal lines and methods, that's fine.

> Yes, I'm anticipating future problems. I figure it's easier to
refactor
> now, than when the codebase gets bigger. I'm refactoring to make future
> refactorings easier, if you will.

Anticipate future problems. Just suffer no speculative code - connect all
code to live user stories, or erase the code. But you can make speculative
refactors all you like!

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Michael Feathers

unread,

Aug 26, 2003, 8:41:27 AM8/26/03

to

"Jules" <ju...@ZZAZZAsitepoint.com> wrote in message
news:ASA2b.63654$bo1....@news-server.bigpond.net.au...

> Hi,
> I'm having a bit of trouble reconciling the "you aren't gonna need it"
> (YAGNI) and "refactor mercilessly" tenets of XP. I'm running through a
> codebase refactoring quite... well, mercilessly! But I'm doing this
because
> I am soon to deploy this codebase into 2 other projects and obviously I
want
> to avoid forking the code. The problem is, my refactoring is now
focussing
> on items I _anticipate_ will cause headaches in the near future.

What are those items? If they are things like, "well, this isn't general
enough, let's parameterize it so we can use it this way later" then listen
to YAGNI. On the other hand, if they are things that make the code unclean
now: "this method is too long, this class is doing too many things" then
that is perfectly good refactoring.

> Yes, I'm anticipating future problems. I figure it's easier to
refactor
> now, than when the codebase gets bigger. I'm refactoring to make future
> refactorings easier, if you will.

One heuristic to use is pride. Ignoring all possibility of future changes,
is this work that I am proud of now? Me? I'm not proud of large classes,
they are confusing. The same with duplication. I know I can do better than
that.

Michael Feathers
www.objectmentor.com

Uncle Bob (Robert C. Martin)

unread,

Sep 1, 2003, 7:24:34 PM9/1/03

to

"Jules" <ju...@ZZAZZAsitepoint.com> might (or might not) have written
this on (or about) Tue, 26 Aug 2003 03:55:12 GMT, :

>Hi,
> I'm having a bit of trouble reconciling the "you aren't gonna need it"
>(YAGNI) and "refactor mercilessly" tenets of XP. I'm running through a
>codebase refactoring quite... well, mercilessly! But I'm doing this because
>I am soon to deploy this codebase into 2 other projects and obviously I want
>to avoid forking the code. The problem is, my refactoring is now focussing
>on items I _anticipate_ will cause headaches in the near future.
>
> Yes, I'm anticipating future problems. I figure it's easier to refactor
>now, than when the codebase gets bigger. I'm refactoring to make future
>refactorings easier, if you will.
>
> Is this a violation of YAGNI?

Yes.

>Am I being silly even bothering to wonder
>about this?

No.

However, rather than anticipating future problems, force them to
happen. Get the two other projects started, and refactor *while* they
are developing. Find the *real* problems, not the anticipated ones,
and refactor for those.

Jules

unread,

Sep 1, 2003, 11:21:34 PM9/1/03

to

> However, rather than anticipating future problems, force them to
> happen. Get the two other projects started, and refactor *while* they
> are developing. Find the *real* problems, not the anticipated ones,
> and refactor for those.

Thanks for your reply. I actually bit the bullet and did exactly this, and
felt like I was making progress once again!

Jules

Phlip

unread,

Sep 2, 2003, 12:51:05 AM9/2/03

to

Jules wrote:

I have a very long name for that pattern. It is "The Squeaky Wheel Gets the
Grease so Run The Wheels Under Load and Listen to them."

But I would entertain any attempts to shorten that name...

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Brian Christopher Robinson

unread,

Oct 2, 2003, 5:55:00 PM10/2/03

to

"Jules" <ju...@ZZAZZAsitepoint.com> wrote in
news:ASA2b.63654$bo1....@news-server.bigpond.net.au:

> Yes, I'm anticipating future problems. I figure it's easier to
> refactor now, than when the codebase gets bigger. I'm refactoring to
> make future refactorings easier, if you will.

I think what you'll find is that the refactorings you did in anticipation
of future changes don't always work out. Some probably will. But you
always could have waited until doing the future work and then done the same
refactoring, also saving yourself the time of doing the refactorings that
don't work out.

Bob Kranson

unread,

Oct 3, 2003, 12:53:58 PM10/3/03

to

Compuware's Package Structure Analysis tool may provide some help/insight:
http://javacentral.compuware.com/pasta/

"Brian Christopher Robinson" <a@b.c> wrote in message
news:Xns9408B642B...@129.250.170.94...