Last night I led a discussion on software quality at the Cleveland area .NET SIG. Thanks to everyone who came and especially to those of you who shared your thoughts and opinions. I enjoyed the discussion and I hope you did as well. This was the first time I’ve done such a talk at this style of group, which typically just has a speaker lecturing for 90 minutes or so, and I thought it went well but of course I welcome any comments.

I quickly looked through the evaluations after the discussion and on the whole they looked positive. I saw a few positive comments, which I appreciate, and at least one comment that I recall where someone said they expected more discussion of process and less discussion of code.

You can download the slides from the discussion/presentation here.

Two topics that I discovered would get the audience participating which weren’t directly in my slides/agenda at all were:

• The importance of comments in code
• The age old debate on whether or not to use stored procedures

Since the intent of the talk is to involve the audience in the discussion, I think I’ll bring these up earlier in the talk in the future, to help kick that off. Coincidentally, I’d just written up a fairly long piece describing my own thoughts on when and how code should be commented, which I didn’t go into too much last night but you’re welcome to read if interested.

One of the key points I tried to make, which was a bit buried at the end of the talk, so I apologize if I didn’t communicate it well, was the question of how can we improve ourselves and our teams so that building quality software is the default? That is, if we define quality software as software that is less expensive to develop (and maintain – all associated costs), and if we posit that some developers are able to “do the right thing” more productively than they can write sloppy code, then the question becomes, how do we get more developers to that state? What tools, processes, learning and teaching activities, etc. work best for to achieve this goal, assuming we agree it’s worth working toward (which I believe it is)?

Oh, and if you like this topic, you might also be interested in the Software Craftsmanship Calendar available from NimblePros. Be sure to check it out.