Agile Prophecies Of Doctor Seuss

The interlocking set of Best Practices, recently named "ExtremeProgramming" by some of its more recent acolytes, derives from a heritage as old as computing itself. Many historical documents allude to both its prevalence and promotion among computer science's early elite.

Some of this source material veils its true intent. But much, however, is as obvious as parodies of Mother Goose nursery rhymes. "Dr." TheodorGeisel, for example, wrote twisters for agile tongues under the pen name "Dr. Seuss", that upon closer inspection contain many of the same lessons.

The literature criticism technique called "deconstruction" helps us "read between the lines" to see what this exact system involved. For example, The Cat in the Hat demonstrates to potential customers that he can hop on top of a ball:

Look at me look at me look at me now!

It is fun to have fun but you have to know how.

This obviously refers to visibility unto a Customer, and also to the fact that this visibility requires careful skill, training, and balance.

But over three pages, the Cat proceeds to add more and more things to his act, one at a time. At the end ...

I can hold up the cup and the milk and the cake!

I can hold up these books! And the fish on a rake!

I can hold the toy ship and a little toy man!

And look! With my tail I can hold a red fan!

I can fan with the fan as I hop on the ball!

Now this cat did not get in this position via supernatural ambidexterity. He got there, over those three pages, by incrementally adding individual elements, one at a time. Only after each one achieved equilibrium with his performance did he add the next. This clearly refers to how programmers add complete features, one at a time, and refactor subsequent features into their designs incrementally.

The Cat himself wrote the UserStories for this stunt; the plot has not progressed far enough for the two children he is entertaining to have learned the CustomerTeam role yet. This is merely a "priming the pump" issue.

The dance appears early in the story; it is a SpikeSolution, and its success is irrelevant. But the team has begun to increment. For the rest of the story the Cat, accompanied by Business Analysts 1 and 2, add more and more features to their project until the ultimate product, a clean house, can be released to their end-user; mom.

This use of iteration is then repeated in The Cat in the Hat Comes Back, which could actually be said to advocate TestDrivenDevelopment. The initial expectation that the bath is clean turns out to be false, so the Cat introduces a minimal solution which meets all requirements. As further tests are added (e.g. "the dress must also be clean"), the Cat adjusts the solution, adding complexity where it is required in the form of new Cats, and ensuring that all currently-passing tests still pass. In the interest of satisfying the final condition that all the snow be white, ReFactoring is introduced explicitly; the Cats first EliminateDuplication between the two types of snow by changing all the snow pink (whilst not affecting the result of any currently passing tests), and then they only need to make one simple change to satisfy the requirement (pink -> white). In so doing, they also note that there is a great deal of complexity in the system which is no longer required (26 extra cats), so this too is removed.

When confronted with a plate of livid Green Eggs and Ham, the typical OnsiteCustomer might just be repulsed off-site. But the ensuing chase scene has a relevant angle for civilians: Sam I Am at no time advises his mark to eat this strange breakfast because "it tastes good". Like any marketing department, he advertises it in association with other irrelevant status-symbols; houses, cars, goats.

Like the first Cat story, the ultimate goal is frequent iterations; adding and subtracting elements from the Green Eggs and Ham experience, until our anonymous customer finally accepts a release for consumption.

This is not good this is not right

My feet stick out of bed all night

But when I pull them in - oh dear!

My head sticks out of bed up here!

Refactoring raises issues which are often solved by more refactoring. A successful design for N features may be wrong for N+1 features. Could a heroic effort have provided for a bed just long enough for any reasonable combination of heads and feet? Of course many such efforts could have. But if heroism fell short, we can rest assure that at any time we can add more design details to provide for just enough coverage for our current feature set.

However, if a heroic guess at design, slavishly implemented, adds more design details than N or even N+1 features actually need, removing those elements is much more difficult than never adding them in the first place. In this allegory, the bed is clearly the number of features required; if the design gets longer than can cover these features, then there will always be more design details than are needed.

The more closely one examines DoctorSeuss literature the more compelling become the many direct and oblique references to software design. But not all illustrate Agility in full flight. The saga of Bartholomew and the Oobleck, for example, takes direct aim at the twin demons of DriveByAnalysis and BigDesignUpFront.

An aging king, despondent over the endless repetition of the changing seasons - heat, wind, snow, rain - summons a team of "weather developers" and gives them a single command, "Make something else come out of the sky!"

Now the problem with this false "requirement" is it did not specify what should come out of the sky, only that a short list of 4 things not come. Developers empowered by a modern DeveloperBillOfRights are required to to reject this lame "UserStory" attempt out of hand. But our weather developers, wize in the ways of magic but not of process, accept this open-ended requirement as if it were a valid project requirements analysis result.

Of course this is just an allegory - a children's fable. The false nature of the DriveByAnalysis is visible at the outset. It builds dramatic tension. But the allegory lays direct comparisons to grownup endeavors. A stack of paper 3 inches thick, describing sticky globular business requirements, emits few if any warnings that, taken together, every single requirement it contains might not create a closed and not open combination with any other requirement in that stack. If the point of "analysis" is to detect this closure, paper inhibits instead of ameliorates the complexity burden.

With the inevitability of a Greek noble tragedy, the BigDesignUpFront phase begins. Forsaking ideals of Visibility or Start Small, the wizards retreat to a mountain retreat - far from the King and far from any more mutual feedback with him regarding their execution of his plans.

Their result is as useless as any signed requirements document containing a flaw which their process cannot detect. They design for a long time, so their plans get bigger and bigger. They design using the organic molecules of nature, so these molecules get longer and longer. Finally, their first execution of their plan covers not a small demo prototype for review; it covers the entire sky over an entire kingdom.

As the crisis falls Bartholomew himself, the King's lowly gopher, remains the only one enabled to debug the system. But his efforts with the king's Knight - representing the End User - fail. Insufficiently warned (no prototyping, demos or marketing), the consumer of the oobleck becomes its victim.

In the end, Bartholomew must urge the King himself to save his own kingdom from the product he himself requisitioned. The King's blessed utterance, "I'm sorry" revokes the requirement. It represents, in a wider context, nobility's evolution beyond autocracy into a "social contract" with the governed. But the direct relevance to software begs forgiveness of the tyrant's assault of the Developers and the CustomerBillOfRights.

In conclusion, evidence of the roots of OO and XP practices in cultural products of our early childhood hearken to more than just the prescience of one child fiction author. The simple primary education that the lessons learned by practicing the modern renderings of the Agile movement map back, too.

---

This is the silliest stuff that ever I heard! -- WilliamShakespeare

Best analysis I've yet seen of ExtremeProgramming. -- AlanTuring

+5, Insightful -- SlashDot

See SarbanesOxleyAct