On May 13, Michele Lanza, Radu Marinescu and me gave a tutorial at ICSE 2008 on pragmatic design quality assurance.

The overall goal of this tutorial was to present the good, the bad, and the ugly about the assessment of design quality, with a special emphasis on object-oriented design. The tutorial was based on the book that Michele and Radu wrote called Object-oriented metrics in practice, on our PhDs, and on the experience gained from building analysis tools and from using them on real systems.

The tutorial had four parts:

1. Software in numbers - Radu gave us an overview of metrics, and he then moved on to present the Overyview Pyramid and the concept of detection strategies to detect design problems.
2. Software in pictures - Michele showed us a perspective of how visualization can provide hidden facets of software.
3. Software in time - I argued that the history is also relevant for assessing software systems, and I presented several combinations of metrics and visualizations to analyze this dimension.
4. Software in tools - For the last part we were joined by Ricky Wettel and we all demoed three tools (Moose, CodeCity and inCode) that showed how quality assessment can be supported by tools. Afterwards, we let the audience play with the tools.

This was the first time I gave a tutorial, and I must admit it was a very nice experience. First, it was the great company of Michele, Radu and Ricky that made me feel very much at ease. We complemented each other very nicely, and in the end we managed to engage the audience. So, I guess the first lesson for me is to always have colleagues you have a great time with.

Second, I enjoyed very much the process of building a story that had to compress a decent amount of information in a rather short amount of time. It was the battle between "don’t we have too much details?" and "do we have enough material for the amount of time?" that made it interesting. This battle was further complicated by the fact that we did not know the audience upfront. Our answer was to opt for less details and be prepared to switch gears if the audience demanded it.

In the end, we did manage to be in time, so it was actually never a question of too few material. And by the amount of questions we received, I believe we did not overwhelmed the audience either. So, I guess the second lesson is that when in doubt choose less details.

All in all, I liked it a lot, and I am looking forward to doing it again.

Here are the slides we used: