Thursday, May 14, 2009

How to: Design and Develop an Application to Ensure its Quality

I gave a presentation last night:


How To: Design and Develop an Application to Ensure its Quality


Victoria University of Wellington, 3rd year “Software Engineering” students (SWEN 301 = COMP 301)


About 30


Thursday 14 May @ 4pm


Ensuring Quality


The first half of my presentation, defining and designing quality, was taken straight out of the book.  Specifically, straight out of the “Analysing Requirements and Defining .NET Solution Architectures” exam.  The second half of my presentation, coding quality, came out of my head and covered training, reviewing and testing.

I could see some heads nodding in agreement as I was speaking, always a good sign.  I could see some heads nodding in weariness, never a good sign.

The question time is always my favourite, because it’s then that I can most accurately gauge whether what I have been saying is “scratching the itch” of the intended audience. 

The first question was along the lines of “great, you’ve told us some more theory, now what about you personally?  What were some of your failures in your career that will help us to avoid pain and embarrassment?”  I won’t record here what I told them in answer, suffice to say it amused them..

The PhD student in the audience had come with slightly different expectations.  I think he was hoping for more concrete examples of measurements and statistics for writing good code.  My rather lame response was that if/when I’m inclined to worry about that kind of thing, then I turn on FxCop to analyse my code for me.

I admitted to being a “lazy coder” in that I enjoy/prefer using objects that I drag onto the page from a toolbox, rather than coding everything by hand.

Definition of terms became important.  I needed to very clearly define “Agile” and “Peer”.  To me, peer programming is not necessarily the Extreme Programming definition of working side-by-side on the same computer.  It just means working as a team on the same project.  To me, Agile just means having many, quick iterations, rather than waterfall software lifecycle methodology.  I hadn’t realised they considered themselves Software Engineers.  To me, there are hardware/network engineers vs. software developers.


Hi James,

Your presentation today was really good. I believe that students love to have you coming from the really world to share your invaluable experience with them. Thank you very much again for your valuable time and your efforts, in particular while you are so busy. I really appreciate it.

Best wishes,
Dr Hui Ma