Extreme Programming Adventures in C#
Authors: Jeffries R.
Published year: 2006
Pages: 242-243/291
Buy this book on amazon.com >>

Chapter 31: Project Retrospective

It is time to assess the XML Notepad project, considering what we would do again next time and what we would do differently.

Learning from the Past

We can do many things to learn our craft. We can go to school, read books, take courses, talk with people, and so on. All of these can give us ideas and techniques that can improve our programming. However, the most important thing of all, in my opinion, is reflective practice. We have to use the techniques we read about, and we have to reflect on the results. In the course of this book, we have reflected frequently on how things are going and we have even tried things different ways and thought about that. Now let s look back at the whole XML Notepad project to see what we might have learned.

There are many good ways to reflect. For best results with a project team, I would recommend that you take a look at Norman L. Kerth s landmark book, Project Retrospectives: A Handbook for Team Reviews (Dorset House, 2001). Norm begins and ends with what he calls the Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities , the resources available, and the situation at hand.

It can be very difficult to do a retrospective for a project and keep the prime directive in mind. For best results on important projects, you may find it best to use an experienced retrospective facilitator. Here, we ll just do our best.



Could We Put This Program into Production?

Our real purpose here, of course, was to write a book about how to develop software in an environment where we have much to learn, and the project was only secondary. Still, we should look at how close the XML Notepad comes to being a production program.

There certainly are features that we would like to add or to improve. File I/O is barely implemented; copy, cut, and paste work, but they are not integrated into our code; the menus aren t organized into a reasonable structure; there is no real ability to view what the resulting document looks like; and the TextBox is limited to 65,000 characters . On the other hand, the program is doing exactly what has been asked of it so far, and it is rather well- tested . We ll come back to the testing issue, and certainly we wish the tests were better, but they re still enough to give us strong confidence that the program works as advertised.

Surprising new features might cause us trouble, although our experience with Undo makes me very confident that we can handle with little difficulty anything that might be thrown at us. Most of the features we can foresee are now just more of the same: more I/O options, more inserts , perhaps a few more intelligent features like adding another P tag or LI tag.

Finally, I suspect that the program may be vulnerable to the user doing things we don t expect. For example, the logic to decide whether to emit a P tag or LI tag looks at the current line to see which to do. A sufficiently complex list item might confuse this logic. If it did, we know exactly where we would have to go to deal with the issue ”to the InListItem() method:

private Boolean InListItem() {

if (Lines.Count == 0 ) return false;
return ((string) lines[LineContainingCursor()]).StartsWith("<LI>");
}

We might have to strengthen that method. That would be the only place we d need to change things.

The feature list might not be as long as the customers would want, but I suggest that the program itself is generally robust and ready to be put into the hands of some interested users. I do suspect that they would find a few problems and that we could write tests for them and fix them fairly readily. Which brings me to my next point.


Extreme Programming Adventures in C#
Authors: Jeffries R.
Published year: 2006
Pages: 242-243/291
Buy this book on amazon.com >>

Similar books on Amazon