NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/pop/71

Internet Message Format | 1992-11-19 | 5.8 KB

From: [e-mail] (Steve Knight)
Date: Thu, 19 Nov 1992 18:42:11 GMT
Subject: Re: Ok, so pop *pop* may be a valid lang, but where's basic?
Message-ID: <[e-mail]>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Path: sparky!uunet!wupost!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hplextra!otter.hpl.hp.com!otter!sfk
Newsgroups: comp.lang.pop
References: <[e-mail]>
Lines: 107

Aaron Sloman writes:
> The difference in productivity between the very best programmers and
> the average ones is enormous, and I suspect that the language they
> use makes only a marginal difference by comparison.

It is certainly true that the difference is large.  (If I remember
correctly, Barry Boehm did one study in which a factor 35 showed up
between the most and least productive.)

However, we tend to measure productivity in a way that minimises the
effect of programming language differences.  I don't produce code any
quicker in Lisp or C.  The key difference is only apparent when I
look at the life-time of the product.  All too often, programming
productivity does not include maintenance effort -- which is where we
see the real payoff.

For example, a key advantage in working in type-safe languages such as
BASIC, Lisp, or POP is that programming errors are never allowed to
execute.  By contrast, when I write in C, my errors don't merely
execute but can cause unlimited havoc (e.g. core dumping, filling
up the file system, crashing root processes, etc)

Back in my GEC days, I recall a software engineering survey finding
that 70% of "serious" defects (I can explain what that meant, if anyone
cares) were due to dangling pointer / space leaks.  And my subsequent
programming experience leads me to think that figure is representative.
Needless to say, I became an immediate convert to the use of
garbage collectors in programming which eliminate this huge category of
serious errors completely.

Typical figures bandied about for the costs of software production
suggest that 70-80% of the cost of software is incurred in maintenance.
Accepting this figure for the moment, we might conjecture that
software costs would be reduced by +50% (70% of 70%) simply by
adopting garbage collection.  I'm not motivated to test this -- I
find it all too believeable -- but I think it would make a super
project.

It is my belief that the choice of programming language (and its
automatically provided technology) is one of the most powerful
influences on software development; I believe it is certainly
more important than the choice of design method.  Studies, which I
have read, that endeavour to examine the influence of language
choice on productivity make a fundamental error.  Without
exception they choose languages from the same technology base,
such as FORTRAN, Ada, Pascal, Algol 6X, and so on.  And all they
go to show is that syntax has no effect -- a truely obvious
conclusion.

But I have a rather cynical observation to make.  Most of the
people I have met who make software methods are so-so programmers
with limited experience of "new" languages.  (I can think of one
exception.)  And "new" might mean post-1970 -- nearly a quarter of
a century ago.  Furthermore, they take no joy in the process of
programming but talk about it as "tedious" or even "menial".  This
is a mindset that belongs to the long-gone heady days of mighty
systems analysts and programmers who were glorified typists.

So, if you accept my observation, it comes as no surprise that these
people produce (dubious) arguments identifying the higher-level of
the software life cycle as where the effort should be devoted.
And the argument I have seen over and over is, when we look
at the software life cycle only 10% of the time/cost is spent in
programming.  But this argument is completely irrelevant when we
factor in the concern that we might be doing a very poor job of
programming.  Maybe we should be doing that 10% differently to
reduce the subsequent 70%?

Evidence for this view can be seen in the regular comparisons of
design methods which show little or no difference between the
methods.  My view is that the most important role of the design
method is to impose a formal framework of communication between
team members.  And this is important in big companies where the
social network is unlikely to correspond with the organisational
setup.  And getting the communication wrong will destroy a project
(always has in my experience, anyway).

Other evidence is that programmers perceive the choice of language
as very important.  In fact, they regard it as so important that
projects can fail when programmers disagree over the implementation
language.  Sometimes we see projects using four or five different
languages to keep the individual members happy.

Furthermore, a large subset of programmers are actively interested
in learning about new programming languages.  This suggests to me
that they see inadequacies in their "toolset" that are so serious
that they are prepared to invest a considerable effort in extending
their experience.

By contrast, I've yet to meet programmers or maintainers who express
much of an opinion about whether they work following de Marco,
Jackson, some fancy new OOD.  There seems to be a general acceptance
that some kind of method is required but a lack of fevour about
which one is chosen.  "Will it solve my problems?" they ask themselves
and the answer is "No" -- exactly unlike their attitude to programming
languages.

So whose problems are solved by software design methods if it isn't
engineers?  Well, the answer is managers.  And will better management
methods really improve software productivity?  You bet they will --
an incremental difference.  But for the big improvements we need to
think about about big technological leaps.

Pish & tush.  I'm running low on gas.  I'd better turn this over to
the raging hordes of methodologists out there ....

Steve