When I was a teaching assistant I was asked to give a talk on ‘Software Quality’ to our incoming junior class which made me realise one thing – you can’t teach software quality!
For a start, it’s so subjective. The narrator in Zen and the Art of Motorcycle Maintenance says much the same things about creative writing. Quality is difficult to define. If you ask students to rank essays (or programs) from best to worst then they will probably be able to reach a consensus – they have an intuitive understanding that one essay has more quality than another – but it’s much more difficult to identify the parts of the essay that give it quality. Over time, with practise and reading, a student develops their ability to recognize that quality. It is the practise then that helps them develop this understanding and an ability to create it.
To me this seems similar to the food tasters Malcolm Gladwell discusses in Blink. The average person can taste Coke and Pepsi and give their preference for one or the other, but may find it difficult to explain why they have this preference. On the other hand, an experienced food taster is able to identify the multitude of flavours in each drink and categorize them by their taste and strength. The food taster, with their well-developed analytical ability, is able to put words to the feelings and intuition that the untrained person has.
With programming classes, students are lectured on the techniques and design patterns that help to produce quality software, but they can only begin to understand where these techniques should be used (and possibly more importantly, the extent to which they should be used) with experience. It’s almost as easy to write bad code by over-applying design patterns and ‘good practise techniques’ as it is to when not using them at all. There is hardly ever one right answer.
I don’t think it necessarily helps that the focus is on writing code rather than analysing the work of other people. As soon as I started working on group projects I think I developed a far greater appreciation for the quality (lack of) of my own code.
Refactoring as an Afterthought
A more obvious problem relating to software quality is the treatment of refactoring as an added extra. When I write a paper I tend to write out the first draft as a long brain-dump saying everything I think needs to be said. That draft is then constantly refactored until I have a cohesive piece of work. In programming (particularly with University assignments) the first draft is often finished when it meets the general requirements of the task, so there is little immediate need to redraft or refactor the work into a better state.
I’m not sure it’s possible to realise the danger of this until you’ve worked on a larger project where poor quality code can lose you days in debugging and refactoring. This is probably the way most people learn of the need for ‘quality’ software anyway.
What Can You Teach?
Beyond teaching students the design patterns and architectures that can help to improve the structure of their code I think the only thing you can do is emphasize the importance of taking an analytical view of code. The best programmers I’ve worked with are constantly unhappy at the state of their own work; continually looking for ways to improve its clarity and structure. Ultimately you can’t really teach that, only motivate the need for it.
There are a few books I’ve read that help in this respect. I particularly liked:
- The Pragmatic Programmer. It’s good at motivating the need for various techniques. Theirlist of tips is good if you haven’t already read this book.
- 97 Things Every Programmer Should Know covers a lot of programming lessons. It’s funny how many of these are basic common sense stories, but it still needs to be said.
There are probably many more, but I haven’t read them yet!
Other books are just good at giving you extra ways to think about and structure problems:
- Design Patterns (Gang of Four or Head First – pick your poison).
- Extreme Programming Explained. You might not agree with all of it, but principles like incremental design and constant refactoring work for me.
- Programming Pearls. I started reading this last week, so I can’t give a complete review, but the first few chapters are great examples of clever programming.
My talk ultimately focused on motivating examples, aiming to get across the pain of doing things the wrong way.