Extremely Spoiled Child

We all know the stereotype: the child with rich parents who always gets what it wants. "I want a sweet", "I want that toy", "I want a Ferrari for my birthday". The parent never ceases to love their child; in the wider community, the child is seen as a spoiled brat.

I see this as a metaphor. ExtremeProgramming tells us to ListenToTheCode. More than that, we should give it what it wants. It want to have a method split: then split it. It wants a new supertype: then split it. The code wants to be fragmented, and you give it what it wants. ExtremeProgramming tells us to be extreme, so give it everything that it wants.

The problem here is that, by listening to what the code wants, you may neglect the wider community. The team producing the code ("the parents") love their child, but people who aren't familiar with the code find that even the simplest algorithm is distributed across many methods and classes. Humans don't like fragmentation. They like sequential scripts. That's why we ask customers to tell us stories!

But don't worry. It is possible to be loving parents without spoiling the child. You must provide an intellectually stimulating environment, suggesting ideas that the child, by itself, would not conceive. We humans are continually inventing new ways to separate and compose ideas. Aspects allow us to describe a problem whilst fragmenting it along the horizontal domain boundaries, not the vertical. We invent IntentionalProgramming ("IP"), SubjectOrientedProgramming ("SOP"), VariationOrientedProgramming? ("VOP"), … The list is endless! These methods all attempt to allow human-friendly partitioning of a problems.

So next time your code tells you that it wants to be fragmented, do your duty as a parent and try to suggest alternatives. Teach you code how it should grow up to be able to communicate with those humans who are not its immediate family. Who knows, it may grow up to be a socially aware adolescent who gets radical ideas of its own!

--DaveWhipp

Cunning metaphor but I'm not convinced. Do we often spoil our code this way or by neglect? Maybe if we see different parts of the system as different noisy and messy children screaming for attention we'll be closer to the mark. Don't have favorites. Keep a balance in your refactoring. Nothing will ever be perfect but you should still aim for it yourself and point your sullen offspring in that direction. What's the system equivalent of throwing everything out of the pram anyhow? -- RichardDrake

Spoiling a child isn't loving that child too much; it is giving the child what she wants when that interferes with what she needs. When you satisfy a child's every want, you keep that child from learning that the world isn't built for their convenience. You fail to teach independence.

What a program wants is elegance. What a program needs (in order to fulfill its function in life) is robust functionality. IMHO, spoiling a program is over-refactoring it, producing CreepingElegance.

I'm not arguing against RefactorMercilessly. RefactorMercilessly works very well when coupled with producing customer valued functionality. Without that, I can refactor a program for five years. I will then have the tightest, fastest, least buggy five-year-old program in the world to compete with state-of-the-art software. Guess which one gets picked--it ain't mine.

--RobMandeville

Great use of the metaphor. I 200% agree. I think of my very first EvolutionaryDelivery project for financial traders, when we produced a $100k result with one morning's work on a new swaps calculator. That sure financed some refactoring! And every project since. There's got to be a balance between RefactorMercilessly and producing customer valued functionality. Yes indeed. -- RichardDrake

I agree that CreepingElegance is a symptom if you always do what the code wants; and I'll agree that its better then the mess caused by neglect (when you don't listen to the code at all). But the real problem I was attempting to highlight is that the code's definition of elegant is not always consistent with human psychology. A state table is a simple, cohesive, thing. When you try to implement it, the code tells you that it wants to split it over multiple classes. Many of the GOF patterns have this fragmentation listed as one of their negative consequences. The use of MetaRefactoring may not be what the code tells you it wants, but it may be what it needs. --DaveWhipp

I hear you emphasizing readability by other programmers. If so, I completely agree. I seldom find under real commercial pressure that "total purity of OnceAndOnlyOnce" or "the very very simplest thing" is a big deal. Total neglect of refactoring has been, again and again. Maybe XP is changing that across the world, big time. As always I like the analogy from music. The most beautiful, pure sound is one note from a single violin. After that the next best (or the much more exciting, depending on your point of view) is hundreds of expert violinists together playing the same note. The minute differences in pitch and volume, plus the inevitable differences in phase, give that wonderful excitement of the sound of the string section in a big orchestra. Such minute variation, imperfection if you like, is to be expected, even welcomed in our code. Anything more isn't, subject to continually delivering "customer valued functionality" as mentioned by Rob. -- RichardDrake

TotalNeglectOfRefactoring is the dirty little secret of almost all large code bodies I have seen. Perhaps I was not diligent enough to qualify employers. Usually the scenario is: Once the Great Elder Gods created a code library. No one has touched or extended the library since. Often the Great Elder Gods are still working on the project. Instead we have CopyAndPasteProgramming carried on for years at a time, giving rise the familiar 20 page while loops.

Once I worked at a job where an embedded system was busting up against a hard 1MB memory limit. A big mistake was trying to support four different models of product with only one program. As a result the code was littered with code along the lines of

  if ((typeFlag & isTypeA) || (isNewType && (typeFlag & isTypeC))),

making it almost impossible to figure out when a line of actual code would be executed, and gobbling about 100 bytes per if. Refactor the while into one loop for each product, getting rid of the ifs and you would have four 3 page while loops that you could at least understand, even if 3 pages is too long for a loop. -- RobertField

Ooo-ee! Boy, do I know that one! Take a quick gander at FixBrokenWindows for my take on that. -- MartySchrader