Fine Line Between Refactoring And Futzing

When is enough refactoring enough? When do you decide that code is good enough for now, and it's time to use it. Once you use the code, you may notice that you need to refactor again. I claim that changing the code without making it better is just futzing. RefactoringLetsYouGoFast, FutzingMakesYouGoSlow.

(BTW, futzing is not in my CollinsEnglishDictionary?, but I believe it is the correct word for pointless tinkering.)

-- JohnFarrell

"Futzing" = the coders equivalent of AnalysisParalysis?

There seem to be several points here:

As soon as the code is good enough, then you can use it (WabiSabi). That doesn't mean you shouldn't fix it later, and there is a separate debate about the right time to refactor: after first draft, before reuse, when debugging, ...
Obviously it's hard to define the QualityWithoutaName. If the refactoring doesn't seem to improve the software, then don't do it. If it's crying out to be done, then do it. If you're not sure, insert FixmeComments.
DebugByDescribing: if you can't justify why the change improves the program, then you're futzing.
CheckDiffsBeforeCommit discourages gratuitous changes by making you justify and explain the update to yourself and through the ChangeLog to everybody else.

-- MartinPool

FIXME or TODO is a very powerful tool in this context. I add a TODO for things I think I want to refactor. This allows me to stay focused on the thing I am doing without forgetting the things I want to do later. The magic is that when I come back to do it later, I frequently find that the idea either doesn't look so good now, or that other refactorings have made the idea unnecessary. FIXME is a programmer's way to do lazy evaluation.

So falling into a trance where you spend hours lining your code up to try and make whatever's compelling you to futz show itself or go away is also futzing, or is that closer to hypoxia or BattleFatigue?? is it common?

When is enough refactoring enough?

When the tests run, everything is done OnceAndOnlyOnce, and all the names make sense together.

See GoFasterWithRefactoring, WhenToStopRefactoring

CategoryRefactoring