A Second Attempt and a Big Mistake

The next time around, I started with a simple mistake that delayed my learning. I wanted to express the operation of Undo as out with the bad lines, in with the good, so I changed this code:

 public void Restore() { 
 if (SavedModels.Count == 0) return; 
 TextModel savedModel = (TextModel) SavedModels.Pop(); 
  lines = savedModel.Lines;  
 selectionStart = savedModel.SelectionStart; 
 selectionLength = savedModel.SelectionLength; 
 } 

to this:

 public void Restore() { 
 if (SavedModels.Count == 0) return; 
 TextModel savedModel = (TextModel) SavedModels.Pop(); 
  this.RemoveNewLines(savedModel);  
  this.AddOldLines(savedModel);  
   lines = savedModel.Lines; 
 selectionStart = savedModel.SelectionStart; 
 selectionLength = savedModel.SelectionLength; 
 } 
  private void RemoveNewLines(TextModel savedModel)  {   Lines.RemoveRange(0,Lines.Count);  
  }  
  private void AddOldLines(TextModel savedModel) {   Lines.InsertRange(0,savedModel.Lines);  
  }  

The problem, which I didn t see, is the line highlighted in the upper example. I intended to replace it with the boldface lines in the lower example, but I left it in. This means that no matter how badly the RemoveNewLines, AddOldLines pair fouls up, the next line fixes the problem by going back to the original, inefficient but working code. Almost no test we can write is going to fail in operation. It might throw an exception, but as soon as the exceptions are all taken out, the code will appear to work.

If tests start failing all over as we work, it s a sign that we need to start over. This particular mistake masks failures: I never got that sign in this attempt and never could!

This time through I tried to focus more on expressing intention , working more top down, and I went in much smaller steps. This is always a good idea when one approach has failed: slow down and take smaller bites. Even with the smaller steps I was feeling uncertainty, but I chalked it up to nervousness from the first attempt. Things seemed to be taking too long, but I pressed on, in part because my tests showed that I was doing well. Unfortunately, my implementation was cheating on the exams.

I continued my basic mistake: I was still assuming that I could just process the lines indicated by the before and after Snapshots selections. This is true, but my reasoning about how it would work was faulty. The right insight, or the right simple test, would have sorted me out. I never had that insight nor wrote that test.

The text describing this attempt has things in it like this is getting scary. I didn t listen to that fear. Instead I slogged on. Finally, two good things happened . First, with all my tests running fine, I ran the XML Notepad manually. It threw exceptions right and left, showing that my tests were weak and off target.

Then Chet showed up to pair with me, and sensing my uncertainty, he talked me into backing out most of the code and starting over. During that exercise, I spotted that fatal line that was obscuring trouble. We agreed to start over, and to use some new tests. Up until Chet arrived, my new attempt had spanned only about seven pages: I was making mistakes much more efficiently now!