Refactoring Equals Reparametrization

An objection against NanoIncrements is that a series of small perturbations in the direction of what seem to be the best direction cannot lead to an optimal system unless the initial design is almost perfect. At some point, the system will appear to be in a local optimum such that we 'must' do a more profound change to the design in order to be able to continue to improve the system by NanoIncrements.

But the shape of an objective function is given by the parametrization of the solution space. Remember how the logarithmic curve became linear on a logarithmic paper? Similarly the bimodal function y = (x^2 - 1) would become unimodal with the parametric shift t = x^2.

Since SoftwareHasNoShape SoftwareHasNoMetric? either, and we can choose the metric as we go. Every time we see a local optimum coming up, we can do a NanoRefactorization, and then continue the walk against the next optimum using NanoIncrements. If there's a global optimum it may eventually be found.

The core of several global optimization algorithms work exactly this way:

 1. Walk in the direction of the steepest descent
 2. Reparametrize
 3. Go to 1

  1. Survival of the fittest
  2. Mutate
  3. Go to 1. ]

So maybe ExtremeProgramming can be formulated analogously as:

 1. NanoIncrements + UnitTests (to go up and prevent slipping backwards)
 2. NanoRefactorization
 3. Go to 1

Now, well, some people like to say that everything (even life) is an instance of some optimization problem, so that software development fits into that paradigm too can hardly be surprising. But anyway...

-- TomHoulder

There's a very important weakness in drawing an analogy between optimization strategies as computers understand them, and refactoring as a way of getting where you need to be: there's a human driving the refactoring process, deciding what to refactor and how to do so. Just as a computer optimization can be greatly improved by having a human watching and directing, the software project benefits from having brains driving the refactoring.

Further, refactoring isn't the only way one discovers optimizations. When a bottleneck (performance or logical) is discovered, the developers think about it and figure out what to try. Then they experiment, then they plug the new implementation into the old system using polymorphism and the UnitTests to be sure it works.

My summary position would be that analogies between global optimization theory and human optimization activity are seriously suspect, and conclusions drawn, if any, need intense scrutiny. That is, they're probably wrong. ;-> --RonJeffries

I tried to carefully avoid drawing any conclusions, just drawing the analogy. So any conclusions must of course be your own. -- TomHoulder Oh yes. And like most of my conclusions, they're probably wrong. --R

"The rule is, 'Do the simplest thing that could possibly work', not the most stupid". -- ChetHendrickson

QuotePage! (falling to the floor in peals of laughter)

I just have to say that while the optimization analogy is suspect, GroupThink and an unconscious inertia could lead a group to feel that their local minimum is optimal. What do I mean by unconscious inertia? Just the things that you would never think of because you are too close to them and they would be too painful.. like switching metaphors in mid-development. Especially when you not only have to change your classes but also your UnitTests. It is a hit x 2. -- MichaelFeathers

This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004