XProgramming
>
XP Magazine
>
Adventures in C#: Sustainable Pace, and the Lack Thereof
COLLECTED TOPICS: Adventures in C# |
Documentation in XP | Book Reviews
Adventures in C#: Sustainable Pace, and the Lack Thereof
08/01/2003
The XML Editor application that is the core of Adventures in C# includes a surprise feature. Without designing for it, we gave ourselves an "Undo" requirement, as a challenge to the idea of incremental design. As you'll read in the book, Undo went in in two very neat steps. First, I wrote a simple implementation that made a copy of the whole text buffer. This implementation went in easily:
Then, for the most common case of a single character being typed in, I implemented a polymorphic Undo object that just saves a single line. This one step saved 99 percent or more of the storage used by the simple implementation. In two easy steps, we got an effective and efficient Undo. Further optimization, if needed, would be straightforward. The reputation of incremental design was saved. Buy the book -- please -- for the details.
But that's not the whole story. In between the first step and the second, I did something bad to my neck. I was in great pain, and it seemed to be paralyzing my arm. I was pretty laid up for about a month or more. It was difficult and very tiring to work at the computer, but I wanted to continue to make progress.
So I did design up front.
I figured that with a little paper analysis and design, I could figure out the pattern of edits, and devise a general way of comparing two Undo snapshots, so as to compress them down to just enough information to do the undo. Here are a couple of pages of my notes on the design:
The reasoning in this design was of course incomplete, and I knew that it was. But I had covered most of the interesting cases, and I was sure that the rest would yield to the design. This solid knowledge of what was before me gave me confidence, so I set out to build a general, theory-based way of comparing two snapshots and producing a compact representation of the change.
This was neat. Usually you do Undo by using a Command metaphor, and by building a kind of "AntiCommand" to cancel out each Command. My solution, by looking at the results, would handle all cases with a single clever scheme.
There was just one problem. It didn't work. One, two, three times, it didn't work. Inspired by this grand design, I went down ratholes, I worked for hours with getting a new test running,. I was plagued by off-by-one errors and other tiny bugs that kept popping up on some new place after I whacked them down in the first location. I knew I could do it, because I had a design. I just couldn't make the design work.
What does this have to do with Sustainable Pace? Well, everything. I set out to do more up front design to make better use of my time away from the keyboard. I knew -- it's why I'm writing this book after all -- that the fastest way was to do it all incrementally. But I couldn't do four hours at the keyboard, so I tried to do two on paper and two on the keyboard, in hopes of going almost as fast.
The design, and the sense of rush, induced me to take bigger bites, with fewer tests. This led to bugs. At the end of my few hours of programming, I wasn't ever at a stable point: I was in the middle. The next day, I would either try to pick up where I had left off -- that is, already unstable -- or I would throw it all away and start over. Same too big bite, because I had a good design after all, a slightly different tack, and a couple of hours later I was tired again, and in trouble again.
What finally saved me was two things. My health began to come back, so that I was able to work in a bit more comfort. And after failing with the big design three times, even I was smart enough to drop the design and go back to what worked: simple, test-driven development. I fell back to one tiny step -- handle a single-character insert -- and in one short session had my 99 percent plus optimization.
Big lessons. Don't work tired. Don't work hurt. When, inevitably, you do, take extra care to realize that you are below par. And don't try to replace small concrete steps with big leaps of fantasy design.