Bryan Moss wrote:
> How do you measure Defects per LOC exactly?
Total number of defects found / total lines of source code in the project. If you want more detail you can break the numbers down by code module, by project phase, or however else you want to (assuming you collected the appropriate details in your defect reports).
Measuring code quality this way makes it pretty easy to tell whether your quality is improving, declining or staying the same. The numbers will tend to do strange things if you change programming languages, but since virtually all commercial applications are written in C++ these days that isn't as big of a problem as it might be.
> The problem is not large programs but unecessarily large programs. This
is
> due to the application-based paradigm. The idea that you have a word
> processor and each new release has extra features, and all these extra
> features add bloat. This is equally true of commercial software and the
> open source community.
I'll take a "bloated" program with tens of thousands of features over a slim program with a few hundred any day. So will most other people, which is why such programs sell. If you prefer the small programs, you are perfectly free to do your word processing in vi, WordStar for DOS, etc.
You might find http://www.slate.com/webhead/99-07-06/webhead.asp interesting.
> A move to component-based software could remedy
> this. But to make coponent-based software work you need to remove the
> programmer from the hardware and the interface, and that isn't going to
> happen anytime soon.
There is also a substantial industry in re-useable components, most notably represented at http://www.componentsource.com/.
Billy Brown, MCSE+I
ewbrownv@mindspring.com