psrc@cbnewsl.att.com (Paul S. R. Chisholm) (01/31/91)
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.john@newave.UUCP (John A. Weeks III) (02/01/91)
In article <1991Jan30.175221.25595@cbnewsl.att.com> psrc@cbnewsl.att.com (Paul S. R. Chisholm) writes: > 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!) How did you get ahold of my current project??? If you are good at this, would you like a job? (just kidding...) Are there variable names like c, cc, and ccc? > 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.) Kill them. One of my clients has spent more than three times the original development cost on maintainence of a specialized statistics program that was poorly developed. Its funny how professional managers can never understand this type of economics. -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!tcnet!wd0gol!newave!john ===============================================================================