CodeInspection

Code inspection is a formalised kind of code review, distinguished by

• Working to checklists
• Keeping stats about 'defects'
• Re-inspecting until code has a low enough level of defects

IMHO (ChrisCottee) unit-testing makes most of code inspection redundant, plus it is a bit heavy weight: you have to gather the stats fairly rigourously before you see the benefit.

Are these really the defining characteristics of a formal inspection? See 1,2 below KeithB

These are the characteristics of software inspections according to Tom Gilb, who based his method on Fagan's. I don't know how much they differ but I don't think by much.

BradAppleton? and KentBeck (and others) hashed this one over on the C2 wiki http://c2.com/cgi/wiki?IssuesOnReviews and http://c2.com/cgi/wiki?ExtremeReviews

discussion moved from XtC04072000

It seems like XP has no place in it for code inspections/formal reviews. This is not so suprising since inspections come from the traditional manufacturing view of quality, and as we know, building software is not a manufacturing process.

There are several aspects of a Fagan-style inspection that seem to be particularly antethical to XP: 1there's a "better" way is not a licit complaint during an inspection. Inspections do not explicitly address maintainability, extensibility, or habitability. A pair of programmers doing refactoring do.

1during an inspection it is not licit to discuss solutions, the inspections exists only to identify defects. The author of the inspection piece then goes off to resolve these defects. Whereas, an XP pair have got the problem, since a test has failed, and are interested almost exclusively in exploring solutions

1Also, a review-based process also includes requirements, architecture, and other committees, which XP spreads throughout the process. There's also a social aspect to inspections which, no matter how kindly done, are about finding fault; much nicer to pair and arrive at a shared solution. --KeithB,SteveF

Interestingly, it looks like manufacturing is moving towards an XP-like view, away from production lines, where teams work in clusters to produce a whole solution -- managing their own quality issues in the process. --SteveF

Yes. Hewlett-Packard, for instance, have used this collaborative/auto-QA model in their factories for a long time, with astounding results, as anyone who's used any of their hardware can attest. My now somewhat old and clunky HP calculator was the best built manufactured object in my house for years, until I got the PowerBook?. Anyone know what sort of manufacturing/QA process Apple use? --KeithB

It's not totally relevant, but a good story. In my Xerox days, we were told that every Xerox copier took a couple of pages to get the alignment right. When one of the Japanese companies started producing small copiers, Xerox bought one and took it apart. No paper dust!!! That is, they managed to build their copiers so well that they didn't need to be manually aligned. --SteveF

-)

Having worked in a factory in a QA/QC lab it's interesting that manufacturing has had a better view of quality than IT has for some time.

Quality Assurance is the process of assuring that the product which has already been produced doesn't go out the door unless it meets certain standards.

Quality Control is the process of making sure that the manufactoring process is performing correctly so that all the product it makes will meet be fit to go out the door.

The best way to produce quality product is not to have someone standanding at the end of the line throughing product into a bin if it's substandard, but to have people making regular checks along the line ensuring that the line it operating correctly at each stage. You can then pretty much gaurantee the quality of the product comming of the end of the line. The QA checks then become a formality to ensure that no unknown variables have been introduced into the process. The whole idea of QC is to get feedback as frequently and quickly as possible. This allows small adjustments to be made the the manufactoring process to keep in within predefined bounds. Thus ensuring that the resulting product will meet QA standards.

Another point that was made to me is that quality is not about producing the best possible product but about producing what is expected every time. If I buy something I expect it to live up to certain standards. If it doesn't I'll be disappointed and not buy that product again. If on the other hand it turns out to be gold plated, I'll probably be dead chuffed until next time when I ask where my gold plated one is and get told that that was just a fluke and I should be thankful.

So more time should be spent on QC (Have you written a proper set to test for this) and then a smaller amout on QA (Have you got a green bar) -- JeffMartin (Quality Assurance Technician)