Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!att!cbnewsl!psrc
From: psrc@cbnewsl.att.com (Paul S. R. Chisholm)
Newsgroups: comp.software-eng
Subject: Code inspections for "mature" code?
Message-ID: <1991Jan30.175221.25595@cbnewsl.att.com>
Date: 30 Jan 91 17:52:21 GMT
Sender: psrc@mtunq.att.com (Paul S. R. Chisholm)
Organization: AT&T Bell Laboratories
Lines: 29

On my last project, we were committed to software inspections.
Somehow, we never got around to them.  There were some problems with
when staff joined (or left:-) the team, and whether and when staff was
working full-time on this particular product, and other details; but I
don't think any of those was the bugaboo.

Our biggest problem is that we had (depending on how much of the
product we wanted to inspect) between 15K and 50K non-commentary source
lines (NCSLs) of C code.  All of it had been written in a hurry, the
original authors were not available to provide much help, and only one
team member knew non-trivial portions of the code at all.  Many of the
functions were very long (the worst offender was a single function with
more than a thousand statements!)  The product was like a large, smooth
ball; we couldn't get our arms around it, and we couldn't dig our
fingers into any useful chunks.

We'd started with the premise that we'd inspect new and changed code.
That didn't work very well; generally, we made lots of little changes
in lots of places.  Inspecting the little changes in isolation didn't
seem worthwhile; inspecting the lines of all the changed functions
seemed overwhelming.

I can see how inspection works for new, highly modular code.  How does
it work when your maintaining dinosaurs?  ("Rewrite the dinosaur" is
not a solution I could have gotten past management.)

Paul S. R. Chisholm, AT&T Bell Laboratories
att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.