P.G. Wodehouse approach to Modeling?

P.G. Wodehouse, creator of Bertie and Jeeves, Psmith, and countless other characters reeking of prewar (WWI, not Iraq) England, is one of my favorite authors (my favorite being Patrick O’Brian). When I am sick or down, or simply at loose ends, I love to get out one of my Wodehouse books and get lost in worries of stolen policeman’s hats and avoiding harassment by elderly aunts.

The Basildon Coder has an article entitled “The P.G. Wodehouse Method of Refactoring”. Now, refactoring is pretty important to a lot of operations research. In particular, for linear programming, the basis is normally kept as a sequence of eta-vectors whose application results in the inverse of the basis matrix. As the sequence gets long, there will come a time to refactor the basis matrix, reducing the eta sequence (see here for some details). What-ho! Bertie (or, more likely, Jeeves) has thoughts on this?

Unfortunately, not, but close. Refactoring in this context is “any change to a computer program‘s code that improves its readability or simplifies its structure without changing its results”, according to wikipedia. So when a computer program is built on over the years, at some point there is a wish to rewrite or otherwise consolidate the code so it is back looking new, ideally with the effects of all the changes intact. Of course, this is relevant to OR also. We often put together models that have been added on to, changed, and modified to within an inch of their lives. And at some point we would like to have the model “we should have written” in the first place. So there is a temptation to toss everything out and start again. In fact, I often recommend doing so in my classes. But that isn’t very good practice, according to contemporary work in refactorization:

Now, the first mistake to avoid here is the compulsion to throw it away and rewrite from scratch. So often when confronted with a vast seething moiling spiritless mass of code a developer throws his hands into the air and declares it a lost cause. How seductive is the thought that 31,000 lines of code could be thrown away and replaced with ~15,000 lines of clean, well-designed, beautiful code?

Sadly, that’s often a path to disaster. It’s almost a rule of the game. jwz left Netscape because he knew their decision to rewrite from scratch was doomed. Joel Spolsky wrote a rant about the same decision – in fact, the Netscape rewrite is commonly cited as a major factor in Netscape losing the first browser war.

The problem is that warty old code isn’t always just warty – it’s battle-scarred.

This is a very good point. Back before I found someone (Hi Kelly!) who could work with me on sports scheduling, doing all the hard work (and most of the inventive work), I tossed away my main sport scheduling models (embedded in thousands of lines of C++ code) two or three times. Every time, the first thing I lost was two months as I remembers why I had in some of the more obscure code conditions in the models. It was always nice to work with “new” code, but it would have been nicer to work with new, commented, code, which never quite seemed to happen.

So where does P.G. Wodehouse come in? When refactoring a large computer code, the author (the Basildon Coder, not Wodehouse) suggests putting up printouts of the code, greatly reduced. The resulting display gives a hint of where code problems occur: lines squeezed to the right are a sign of deep nesting in loops, dense mass is often overly-complicated code, and so on. And this reminded him of Wodehouse:

The first time we pinned up the printouts, I suddenly recalled a Douglas Adams foreword reprinted in The Salmon of Doubt. Adams was a great fan of P.G. Wodehouse, and explained Wodehouse’s interesting drafting technique:

It is the next stage of writing—the relentless revising, refining, and polishing—that turned his works into the marvels of language we know and love. When he was writing a book, he used to pin the pages in undulating waves around the wall of his workroom. Pages he felt were working well would be pinned up high, and those that still needed work would be lower down the wall. His aim was to get the entire manuscript up to the picture rail before he handed it in.

(Adams, 2002)

This actually seems like a pretty good way to write models, and to write papers. When I write a paper, I generally work on a sentence-by-sentence level, and only rarely look at a the big picture. So perhaps when you visit me next, I will have two sets of papers pinned to my wall: my current optimization model, and my current journal submission-to-be.

By the way, be sure to click on the illustration to get to the site of Kevin Cornell, who looks to be a very talented and humorous illustrator to me!

Leave a Reply

Your email address will not be published. Required fields are marked *