Re: "Selling" a code-audit.

I think the final goal of code auditing is helping to make better code.
In the long term, it is more important a successful project with robust 
code than a successful 'code-audit'.
The code-auditing must promote robust code, defensive programming and 
'teaching lessons', not to detect guilty people, and the guidelines for 
this are under the 'common sense' label. We can learn the lesson of 
Quality assurance from other industries, the japanese car industry 
revolutionized productivity with the 'Zero-defect' initiative, of each 
member of the team -and the company- being a Quality Auditor, instead 
of supervising the project 'after the facts'.
- Take the problem before it is born, then it is easier to deal with, 
and it resolves itself, paraphrasing Lao-Tzu.
- Start early in the development process: it is better if one starts 
working with the team before the project begins,  and is part of it 
(being everyone informed of our auditing or supervising activities). 
One is better positioned if is part of the team - even at the risk of 
losing some objectivity -.
- One could anticipate the problems by way of suggesting 'A  
methodology', a set of rules or 'best practices' to the developers at 
the beginning, this will reduce the 'stress' level of the participants, 
and make them more collaborative. And fewer defects will be detected, 
because there are less, not by problematic relationship with the team 
and obscurity.
- Auditing must be like 'a movie' which helps in building the project, 
instead of a 'post-mortem' picture of what was wrong. Of course there 
will be situations when there is no alternative than do a post analysis 
of what went wrong, but we need to keep focus on the long term, and use 
the pareto's law (80/20) for an approach.
- We need to support development methodologies which promote 
peer-review, pair programming, such as 'eXtreme Programming' or XP, 
which in general are more robust practices and better at 'defensive 
programming', are more proactive methodologies, and easier to follow 
too. And when dealing with a team which have such practices, they will 
not be 'at a defensive position' because they will  see you as part of 
the process, and as part of their team. Then the whole team (including 
the code auditor) will be successful.
Best regards,
Javier Blanqué

> -----Original Message-----
> From: Yvan Boily [mailto:[email protected]]
> Sent: segunda-feira, 30 de agosto de 2004 14:45
> To: [email protected]
> Subject: "Selling" a code-audit.
>
>
> One of my primary responsibilities with my employer is performing code
> audits; so far I have been fairly effective in a technical capacity,
> however
> on almost every single code audit I have participated in I have
> received
> hostile responses from the development team.  I have tried a variety of
> approaches to develop a stronger rapport with the development team,
> however
> in spite of my best efforts I find that going into a code audit I am
> already
> fighting against preconceptions about why the code audit is being
> performed.
>
>
> I understand that many people feel threatened when work they have done
> is
> criticized; what I need to know is how I can minimize this and coax the
> development teams into being more interactive than defensive.  Any
> pointers?
>
> Yvan Boily
>