Re: Software Metrics (cat flame > /dev/null)

Many decades ago I worked for a well-known company
that made testers. They had a nice bonus for the
engineer that designed the board with the fewest
field failures. The engineers regularly fought hard
to design a memory board, which was a shoe-in to
win the prize (compared to the tough analog front-
ends exposed to regular customer abuse).

They also didn't count labor hours in the metrics
for board cost. That led them to take out of
production a UART board using an *expensive*
crystal and reintroduce its predecessor, which
had hand-tweaked-and-soldered RC frequency
generation. They also discontinued a subsystem
using ribbon cables to reintroduce hand-soldered
cable bundles because it was *clearly* less expensive.
BTW, labor was even expensive in USA back then.

I could go on for hours...

Most metrics used don't reflect what most of
us would consider reality. Software metrics in
use today lead to outcomes just as silly as
those listed above...

Hope this was entertaining and maybe even helpful,
Best Regards, Dave

Hi Dave,

On 7/15/2011 12:45 PM, Dave Nadler wrote:
> Many decades ago I worked for a well-known company
> that made testers. They had a nice bonus for the
> engineer that designed the board with the fewest
> field failures. The engineers regularly fought hard
> to design a memory board, which was a shoe-in to
> win the prize (compared to the tough analog front-
> ends exposed to regular customer abuse).

Presumably, this was for semiconductor memory (and not
core planes :> )...

> They also didn't count labor hours in the metrics
> for board cost. That led them to take out of
> production a UART board using an *expensive*
> crystal and reintroduce its predecessor, which
> had hand-tweaked-and-soldered RC frequency
> generation. They also discontinued a subsystem
> using ribbon cables to reintroduce hand-soldered
> cable bundles because it was *clearly* less expensive.
> BTW, labor was even expensive in USA back then.

I don't understand. Are there two different criteria at
play, here (cost and failure rate)?

> I could go on for hours...
>
> Most metrics used don't reflect what most of
> us would consider reality. Software metrics in
> use today lead to outcomes just as silly as
> those listed above...

But that, I think, is because the metrics are being used
for "business purposes" (cost accounting, etc.).

E.g., I just coded a "unified memory manager" to replace
the various different *types* of memory management
mechanisms used in many embedded systems. Once I've
given it a thorough shake-down in an application, I
will go back and write comparable "traditional" tools
to provide the same functionality. *Then*, I will
see what their "metrics" look like to help me evaluate
the utility (or disutility?) of this new approach.

I.e., if the new approach is *conceptually* more complicated
but "metrically" simpler/smaller/etc., then that speaks to
reliability, maintainability, etc. in a way more readily
defensible than some emotional "hand-waving".

> Hope this was entertaining and maybe even helpful,

Someday, someone will collect, catalog and publish all
these anecdotes so we can relive the chuckles in our
"declining years" :>