Refactoring War

The code is pushed in one direction then back in another direction because there are two notions about in which direction the code should go.

Can't we agree on a design and give it a try in good faith? Obviously not.

How about we do two SpikeSolutions and compare them? No one wants to, I see.

Oh well, I guess we'll keep shoving the code back and forth and get mad at each other. What? Now we're not even in agreement about the CurlyBraces?? Gosh, I'm glad we're all adults!

... Hey, maybe these PairCliques are hurting us ....

-- Mous (A non 'e' mouse)

I was in a RefactoringWar once. It was about 15 years ago. A member of the GeneralDynamics? ArtificialIntelligence lab by the name of DaveNicholson? and I disagreed on whether it was better to use the loop or the map functions of ZetaLisp?. That summer he and I switched off vacations such that someone was always in the lab to fix problems. When ever I left for vacation Dave would rewrite all of our code to use loop. Whenever Dave left I would rewrite all of our code to use map. Now the difference between loop and map was not trivial per say so lots of things needed to be changed. It took a some work, but it was just so amusing to see the reaction when the other person came back from vacation and all the maps or loops were gone.

So the first important thing to note is that we laughed about the war and didn't let it make us angry. We could have gotten all upset and argued, but we respected each other enough to realize that there must be some truth to what the other person was saying. Eventually we both learned how to use loops and maps when it was appropriate and not to be fanatical.

Another important thing was the resulting code. By refactoring back and forth over time we worked our inference engine down to a few pages of well-written code. Each time it was reworked it got a little bit better, simpler, cleaner, and easier to understand.

Now I would not recommend an out right RefactoringWar. But differences of opinion are not necessarily bad. Pushing the code around can help you find the design that the code ultimately craves for itself not unlike the way a OuijaBoard works.

DonWells

And who has won the war? -- HelmutLeitner

Well, since this is the kind of war in which (hopefully) neither of the combatants are killed, this could theoretically go on forever. If neither of the participants are willing to cede any ground, then any victory at all is temporary and pyrrhic. But, if (as in DonWells' example above) both participants are willing to learn from one another, RefactoringWar could quickly turn into ThesisAntithesisSynthesis, at which point both parties win.

This is a theoretical, idealistic viewpoint, just as saying: "In a real war there are only losers." I'm interested in the story, and I'm eager to hear it's end. -- hl

Typically I've seen RefactoringWar cause a reversion to CodeOwnership. If the "warring" parties can't come to an agreement, one of them says "it's my code; I'm doing it this way; keep your hands off it" and the war stops. The bad feelings don't stop but the war stops. -- JeffGrigg

Who is winning the war? Well, no one has said, "this is my code," but everyone knows what things will cause a fight, so either an assertive person will make a change and cause a fight, or a less outspoken person will avoid making a change and do something less simple just to avoid a fight. In general, the aggressive are getting their way. And the less aggressive of us are getting disenfranchised. (Squeak!)

-- Mous (A non 'e' mouse)

I'm a little surprised that nonfunctional requirements have not been introduced to the discussion yet. When designers argue about which is the correct design without making any headway, what are they missing? -- WaldenMathews

Here is what they seem to have missed:

"So the first important thing to note is that we laughed about the war and didn't let it make us angry. We could have gotten all upset and argued, but we respected each other enough to realize that there must be some truth to what the other person was saying. Eventually we both learned how to use loops and maps when it was appropriate and not to be fanatical."

"Another important thing was the resulting code. By refactoring back and forth over time we worked our inference engine down to a few pages of well-written code. Each time it was reworked it got a little bit better, simpler, cleaner, and easier to understand."

The end of the story is that both sides learned the others methods, and the code got better.