, McConnell defines 15 'characteristics of software quality':
It's important to work out early on in a project what your priorities are (and especially what they aren't) so that you can steer the project effectively. It's also important not to underestimate the effect of all the unspoken tacit decisions made by developers in the course of their work: the unspoken assumptions. Without clear guidelines, developers will benignly pursue their own ideas about 'the right way' to do something. You can tick off all the use cases you like, but if they favour performance or reusability, and your client's real goals are accuracy and maintainability then you're heading for trouble. It’s always the non-functionals that bit you, IMHO.
Fortunately McConnell also points out that given clear guidance, developers will actually do what they're told, which is reassuring. Setting clear goals is a pretty key management tenant, but one easily forgotten. Some of these characteristics (say performance, code-complexity) can even yeild metrics, so you can deal with the project graphically: BigVisibleCharts
On my previous project, we used this list as the basis for our peer code reviews, out of which came the categorisation I posted previously
, but to re-iterate (slightly re-worded):
- Customer Facing (most of the External Characteristics)
- Maintenance and Design (most of the Internal Characteristics)
- Defects (Just hunting for bugs)
I think it’s a good split. Each review role had a cheat sheet which consisted of the relevant characteristics (as defined above) to look for, and some check lists. This helps ensure visibility of the quality priorities into the code review, which makes them doubly hard to ignore.PS: If you weren't sure what some of the characteristics meant, maybe you should re-read your copy of CodeComplete.