APL Program Code Metrics

Keywords:
In article <12a7b6f6-4342-4159-aade-27d7d95b5a8e@l42g2000hsc.googlegroups.com>, crishog <google@4xtra.com> wrote:
<snip>
>My brother is an engineer - a mechanical engineer that is. The
>impression I get of how he works though is more of an artist hand-
>crafting something rather than it being a coherent science. He says
>that often, even when following all the rules precisely, they don't
>know if a machine will work until it's been built. Hence the
>recognized need for prototyping, at least in mechanical engineering:
>and never get him started on the problems of taking a working device
>measured in American units & trying to built the same thing in
>Imperial or Metric measurements.

My favorite story about CAD for mechanical engineering was from a Viet
Nam war era article about the development of an automatic (machine gun)
grenade launcher for the US Navy. They were all very excited about their
new finite element analysis mechanical CAD tool. They carefully designed
& built the launcher with plenty of safety margin according to the stress
analysis computations. They fired one shell & it worked perfectly, as
did a second and a third individual shot. They then loaded the magazine
with three rounds, set it to automatic, and it tore itself to pieces.

The chief engineer examined the wreckage, beefed up everything that broke
by an amount his experience said should be adequate, and that was that.

Although it's perhaps a bit of a stretch to apply this as a metaphor for
some programming endeavours, it's not too far off the mark.

Doug White

On Jun 22, 11:25 am, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> Suppose I have a group, three or more, humans who are working on some
> code base. Two people working together perhaps know each other and
> their respective coding habits rather well. But with three or more,
> invariably the individuals become more disconnected. All too often,
> one hears the phrase "This code is $#@% !"

I'm inclined to agree with you and the Extreme Programmers about the
importance of this issue. A coding team is writing for each other's
eyes. Famously, the XP people think code quality so important that
no one may check in production code unless it's been written with at
least one other team member.

I'd take their view to be that the issue is too important to leave
to metrics.

Stephen Taylor
editor@vector.org.uk
http://www.vector.org.uk
http://aplwiki.aplteam.com

Lets say you have two programmers.
They each deliver 1 function every day.

Programmer A is working on project B.
After 50 days programmer A is also fixing 10 problems in project B
every day.

Programmer C is working on project D.
After 50 days programmer C is still only delivering 1 function per day
because there are no bugs in project D.

It is possible to claim that programmer A is more productive because
he is delivering 10 fixes and 1 new function every day.

I have seen similar cases over and over.
Programmer A is a hero because he is so good at fixing problems.

On Jun 23, 9:02 am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:

> I'm inclined to agree with you and the Extreme Programmers about the
> importance of this issue. A coding team is writing for each other's
> eyes. Famously, the XP people think code quality so important that
> no one may check in production code unless it's been written with at
> least one other team member.
>
> I'd take their view to be that the issue is too important to leave
> to metrics.
>

But XP does try to measure such things as "project velocity" - and I
would have thought you could only do that by knowing something about
what the team has produced, other than the weight of the printout.
But:

On Jun 23, 10:03 am, Gosi <gos...@gmail.com> wrote:

> I have seen similar cases over and over.
> Programmer A is a hero because he is so good at fixing problems.

As I said in my first posting: "The intention was to give guidelines
to the developer on the "opinion" of the process on his/her code. It
wasn't really meant for a manager who would use it out of content."

These tools are best used within the team itself, to assist with
things like project velocity & the "social change" which seems to
evolve from an iterative quality improvement scheme. Though I seem to
be espousing them, I don't believe the metrics have universal
objective meaning.

Chris

Ibeam2000 wrote:
> Recently, one of my clients started using Visual Studio 2008, and one
> of the new features is something called Code Metrics. In short, this
> feature generates a statistic, a "maintainability index" (MI) for
> every program.
>
> The formula is something like
>
> MI := 171
> - (5.2 * ln(halstead volume))
> - (0.23 * cyclical complexity)
> - (16.2 * ln(lines of code))
>
> This looks as if it would work for APL code with control structures.
> (Cyclical complexity is basically a depth count of nested loops, if
> statements, case statements, and so on) (How would one do this
> meaningfully for legacy branching?)
>
> Has anyone ever done anything like this for APL functions?

IEEE Software had a few articles some years ago on function point
analysis (there may have been others, but I'm no longer a member)

one protagonist conceded that the analysis needed to be tuned not only
for the language in use (and APL was included in the survey), but also
for the analyst

so much for comparability!

I would have thought similar comments apply here - you may get
comparable results for scalar-processing imperative languages, but for
APL, SQL, ML, Prolog, Scheme, assembler...? I doubt it very much

as others have already pointed out, any results would surely be
comparable only within a very local radius

it's interesting that the formula doesn't appear to consider
object-orientation as being a significant factor

/phil

"phil chastney" <phil.hates.spam@amadeus.munged.eclipse.co.uk> wrote in
message news:nwU7k.79009$tn2.45025@fe07.news.easynews.com. ..
> Ibeam2000 wrote:
>> Recently, one of my clients started using Visual Studio 2008, and one
>> of the new features is something called Code Metrics. In short, this
>> feature generates a statistic, a "maintainability index" (MI) for

[...]
>
> IEEE Software had a few articles some years ago on function point
> analysis (there may have been others, but I'm no longer a member)
>
> one protagonist conceded that the analysis needed to be tuned not only
> for the language in use (and APL was included in the survey), but also

[...]>
> /phil

oh, gosh, the fpa, the nightmare for an APL-er ...
I remember this from the early to half the 90ties; the programmers in my
office where idolated of that - (it was new! and they thought they had a
yardstick - for what??)
Even before they knew what fpa was it was done ... in APL. Really.

Stephen Taylor <editor@vector.org.uk> wrote:
> This thread encourages me in my view that writing software is more
> like writing than it is like engineering.

I would say like a cross between writing and mathematics.

> "Program Code Metrics" sounds a reasonable subject for engineers to
> study. Contemplate an equivalent for, say, novelists, and the eyes
> pop.

Personally, I think it a good subject for a team of psychologists
provided there's enough of them that they never reach any conclusion.

Later in this thread someone brought up XP. I have yet to encounter a
piece of M$ software that I would consider reliable.

APL2 for OS/2 is probably the most reliable piece of software I have
encountered and I'd bet no program code metrics were used by the
development team.

Ted

On Jun 23, 7:27 pm, Ted Edwards <Ted_Espaml...@telus.net> wrote:
> Stephen Taylor <edi...@vector.org.uk> wrote:
> > This thread encourages me in my view that writing software is more
> > like writing than it is like engineering.
>
> I would say like a cross between writing and mathematics.
>
> > "Program Code Metrics" sounds a reasonable subject for engineers to
> > study. Contemplate an equivalent for, say, novelists, and the eyes
> > pop.
>
> Personally, I think it a good subject for a team of psychologists
> provided there's enough of them that they never reach any conclusion.
>
> Later in this thread someone brought up XP. I have yet to encounter a
> piece of M$ software that I would consider reliable.
>
> APL2 for OS/2 is probably the most reliable piece of software I have
> encountered and I'd bet no program code metrics were used by the
> development team.
>
> Ted

At one point in time, I made the windows/OS2 choice. Chose windows,
because of
the groups I was teaching. Still have the system but it needs a bit
of fan replacement
cleaning, ... It's been rock solid. Not fancy; slow but I'm used to
running it and going
to bed. APL2 is what I think-in. I've never realized that I need
anything better.

Not saying OS2 wasn't better than win3.1; just sayin APL2 was the
key. Metrics, to me, is
an exercise for software pro's. Wish em well, but I know what
works.

For customers, I wrote code with comment of what the code was doing,
with ref's to the
data structure and the algorithms used. With the view that they (the
customer) could redo
the program in pascal or ... if they had need later. It worked.

Marv in Lex, KY

Gosi wrote:
> Lets say you have two programmers.
> They each deliver 1 function every day.
>
> Programmer A is working on project B.
> After 50 days programmer A is also fixing 10 problems in project B
> every day.
>
> Programmer C is working on project D.
> After 50 days programmer C is still only delivering 1 function per day
> because there are no bugs in project D.
>
> It is possible to claim that programmer A is more productive because
> he is delivering 10 fixes and 1 new function every day.
>
> I have seen similar cases over and over.
> Programmer A is a hero because he is so good at fixing problems.

I worked at a place (an APL shop) where Programmer A, who didn't believe
in testing his stuff and therefore worked somewhat "faster," ended up
having to work a weekend making fixes to his code after an important
site hit the bugs. Programmer B, who also worked on the same project
but did test his stuff, didn't end up with any bugs to fix. Programmer
A ended up being recognized for going above and beyond the call of duty
because he sacrificed his weekend "for the good of the project." Even
got a monetary award, I believe. No recognition for Programmer B.
** Posted from http://www.teranews.com **

On Jun 24, 7:33*pm, Rav <Pa...@cais.com> wrote:
> Gosi wrote:
> > Lets say you have two programmers.
> > They each deliver 1 function every day.
>
> > Programmer A is working on project B.
> > After 50 days programmer A is also fixing 10 problems in project B
> > every day.
>
> > Programmer C is working on project D.
> > After 50 days programmer C is still only delivering 1 function per day
> > because there are no bugs in project D.
>
> > It is possible to claim that programmer A is more productive because
> > he is delivering 10 fixes and 1 new function every day.
>
> > I have seen similar cases over and over.
> > Programmer A is a hero because he is so good at fixing problems.
>
> I worked at a place (an APL shop) where Programmer A, who didn't believe
> in testing his stuff and therefore worked somewhat "faster," ended up
> having to work a weekend making fixes to his code after an important
> site hit the bugs. *Programmer B, who also worked on the same project
> but did test his stuff, didn't end up with any bugs to fix. *Programmer
> A ended up being recognized for going above and beyond the call of duty
> because he sacrificed his weekend "for the good of the project." *Even
> got a monetary award, I believe. *No recognition for Programmer B.
> ** Posted fromhttp://www.teranews.com**

The best programmers are intelligent and lazy.
They tend to make tools to assist in everything.
If you are a fast typist and always remember everything you end up
forgetting to put in important lines in the system.
Also the fast programmer is always fixing the system on the fly while
running the program and does not bother to fix small problems.
If you always start your program from the beginning and after fixing
something start again until it runs without problems you may be
considered lazy for not being a fast fixer.
The intelligent part can be good too but is far less important.
Intelligent and fast can be a deadly situation especially if you are
an APL programmer.
If you are only lazy and not very intelligent you are probably not an
APL programmer.