Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!tivoli!alan From: alan@tivoli.UUCP (Alan R. Weiss) Newsgroups: comp.software-eng Subject: Re: Code inspections Message-ID: <346@tivoli.UUCP> Date: 1 Feb 91 01:33:26 GMT References: <14964@megatest.UUCP> Reply-To: alan@tivoli.UUCP (Alan R. Weiss) Organization: Tivoli Systems Inc., Austin, TX Lines: 162 Cc: alan@tivoli.com In article <14964@megatest.UUCP> pat@megatest.UUCP (Patrick Powers) writes: >It seems that the problem with code inspections is largely emotional. Actually, my belief is that it is *also* temporal: developers believe that it takes up a lot of time. When proven otherwise, they are more receptive. At that point, *some* people have reservations based upon BAD inspections, or poorly-trained inspectors and moderators, or simply the THOUGHT of inspections. Also heresay plays a part. >Though there is plenty of evidence that code inspections are cost >effective, I believe they would tend to be boring and stressful. Its a funny thing about boredom. In a small start-up like ours (Tivoli Systems), everyone has a stake in the success of our firm. If something is proven cost-effective, our developers are absolutely behind it 110%. If it is a time-waster, they chafe. The challenge is two-fold: first, to PROVE the merits of inspections, and that can be done in a number of ways: case histories, measuring your own development/quality statistics, cost analysis, faith, etc. :-) The second challenge is more fundamental: how do you get developers to view themselves as software engineers (i.e. professionals)? How do you get developers in BIG corporations with a diffused sense of ownership and responsibility (and reward) to get excited about cost savings? And THAT is a management challenge. Good management is constantly selling ideas and motivating their staff, challenging them to link the development plan with the business plan in their own minds, and thence to THEIR plans. >Boring because they are a time consuming and non-creative activity -- >current issue of IEEE Software recommends 150 lines of code reviewed >per man-day as a good figure. I know I would not want to do this, and >who would? So, I can assume that you are advocating that no one actually READS the source code? No? Then why not actually track issues and actions? Inspections, done well, SAVE time. Guaranteed! Besides, the time saved is the back-end development time (you know, the ol' release/ test the bugs/return to development/fix the bugs/ad nauseum cycle. Developers get REAL bored with fixing bugs all the time, right?) At Tivoli, I am VERY fortunate to have a group of developers and managers who believe in inspections (a QA Manager's dream!). We started this process, and guess what? The developers are totally convinced that it will save them LOTS of time later. We're finding bugs in all kinds of deliverables (specifications, manuals, source, etc). I promise to keep this newsgroup appraised of the process (special thanks goes out to Kerry Kimbrough, a very brave Development Manager indeed who started this process at Tivoli). >Stressful because it is out of the programmer's control, >and because criticism is involved. People identify closely with their >creations and find criticism painful. Bzzt! Wrong. In Fagin Inspections (as modified by Tom Gilb), ONLY the developer gets to prioritize and rank the incoming defects. The actual inspections occur off-line individually, and the Defect Logging Meeting is simply a fast recording of defects. Afterward, the developer MUST respond to every item, but can in fact choose his/her response based upon engineering principles. QA's function is to serve in a consulting capacity, continually working with the community to correlate requirements with design with implementation. Besides, haven't you read Gerald Weinberg's "The Pyschology of Computer Programming?" Ever here of ego-less programming? All programming is iterative!!! Its just a question of solving problems earlier in the product's life, or later (i.e. in support). >Not only that, but your average programmer was very likely attracted to >programming in order to avoid social interaction and to create >something under his/her personal control without anyone else watching. Maybe. But I don't *think* so. Programming is an intensely SOCIAL activity. In anything other than a one-person shop, programmers MUST interact with each other. Sure, the culture is different that interactions between, say, hairdressers in a salon (hello, Laurelyn!). But there is ALWAYS a prevailing culture, and that implies society. Again, Weinberg is the guru in this. >He/she is likely to be on the low end of the social tact scale and >singularly unqualified to deal with this delicate situation. Lucky thing I'm reading this before my staff sees this! They would take exception to this, and so do I. Programmers may be different, but the stereotype of a hacker-nerd is insulting and gross. >Again, this may very well have attracted them to programming: it doesn't >matter whether anyone likes their personality, all that counts is >whether the program works. Maybe in school. They don't teach software engineering, or how to actually run a business based around software in most CS programs. Programmer's find out FAST how the real world works when someone actually pays them (large sums of) money. They find out that "working" is trivial; its optimization, schedule, cost, maintainability, and a number of other factors that count. Including teamwork, dude. >In order to reduce these problems the following has been suggested: >1) The author not be present at the inspection >2) Only errors are communicated to the author. No criticism of style allowed. You need to study Fagin. Also, Kerry (and some of the net.people :-) turned me onto Tom Gilb: absolutely fabulous stuff. Your ideas are too primitive. You really need to study this subject first. Lemme know if you want help! >I've toyed with the idea of instituting code inspections but just >couldn't bear to be the instrument of a good deal of unhappiness. I assume that you don't want to tell them that they are laid-off, either, due to lack of sales, right? Is a friend someone who tells you nice-sounding lies, or is a friend someone who tells you the truth? Whatever happened to courage? You get courage by being sure of your facts, by researching matters, and by measuring success and then selling the hell out of it. Test the waters! >It seems to me that it could work with programmers directly out of college >who feel in need of guidance. It also might succeed in a large >paternalistic organization as these would be more likely to attract >group oriented engineers. Note that the classic studies of code >inspection occurred at mammoth IBM. Yet often even IBM does not do inspections (I speak from personal experience). Yes, they have studied inspections and methodology for over 20 years (so has TRW), but then again they have the money to do pure research (see also Software Engineering Institute at CMU and Purdue's program). Still, inspections work regardless of organization size. >In spite of all this, I think code inspections would be accepted in any >application where there is a clear need such as the space shuttle >program where reliability is crucial and interfaces are complex. Another funny thing, Patrick: why do people think that life-threatening applications are more important that business-threatening applications? To a small business owner, software bugs can literally KILL his/her business. To THEM, there is a clear need, right? They would rather die then see their "baby" croak. >... On the other hand in routine applications with a good >deal of boiler plate code they could be a "real drag", exacerbating the >humdrum nature of the task. Maybe. But "boiler-plating" should be treated as such. However, I've seen cases where people *think* its template, but its not. Expensive, evil cases. Costly cases. And THAT is a REAL drag :-) .-------------------------------------------------------. | Alan R. Weiss | | Manager, QA and Mfg. _______________________________| | Tivoli Systems, Inc. | These thoughts are yours for | | Austin, Texas, US | the taking, being generated | | 512-794-9070 | by a program that has failed | | alan@tivoli.com | the Turing Test. *value!=null;| |_______________________________________________________| |#include "std.disclaimer" --- Your mileage may vary! | .-------------------------------------------------------.