Why Projects Fail

[David Vaughan]

On Monday, March 25, 2002, at 04:21 , Rob Cozens wrote:
>
> A couple of personal observations you are welcome to comment on:
>
> 1.  The advent of larger & cheaper mass storage & RAM, plus faster CPUs 
> have shifted the primary programming emphasis from compactness & 
> efficiency to readability & maintainability.  If programmers (moi 
> included) put as much effort into writing & documenting maintainable 
> code as we put into finding the way to implement an algorithm in the 
> fewest (or logically most efficient) statements, we would be taking a 
> step toward eliminating the kinds of failures you are investigating.
Very true and, I think, exactly what has been happening progressively 
over many years. I use the comparison between C (C++) and Java as the 
paradigm of this change. Java when it emerged was promoted as write-once 
run-anywhere and as providing a "secure" (not dangerous) scripting 
language for web browsers and the like. However, I believe the prime 
reason for its adoption in the enterprise is precisely its lack of 
handles and pointers which leads, I think directly, to a an increase of 
2-3 times in programmer productivity compared with C++ (See 
Capers-Jones). The improvement happens in large part because writing and 
especially debugging is faster when you are not having to use debuggers 
with breakpoints and variable inspection to discover that the handle you 
thought you had is actually something else. At run time an erroneous 
reference is usually pretty tragic in its consequences and customers 
rapidly lose patience with this sort of thing.

I am familiar with a very large manufacturing plant which in the 80s 
wrote a beautiful messaging product to support distributed process 
control in the plant. Now, they are paying licence fees to IBM for 
MQSeries and a significant reason for that is that they found their 
home-grown application, while perfectly efficient and reliable as it 
stood, was no longer maintainable for minor tweaks to to transfer to new 
platforms - tricky code and lack of documentation to follow the strands 
of spaghetti.
>
> 2.  IMFO, one of the aspects contributing to the difficulties 
> associated with pointers and handles is the syntactically cryptic 
> method by which they have been implemented in C and other languages. I
Not sure. You might be right. I thought using Variable 
@{handle_to_}Variable @@{pointer_to_}Variable had its own merit as a 
structure.
>
> 3.  For moi personally, the goal is to enable direct system calls from 
> Xtalk.
Can we do this by any other means? You are familiar with CompileIt!. 
There, although we could return handles to the HyperTalk script, we 
normally used them in the compiled code and CompileIt! provided the 
toolbox data structures or handled the translation from HyperTalk 
variables to code variables you could stuff in to the structures. This 
is my preferred approach. Not to make system calls an immediate part of 
xTalk but to provide an add-on, a portal if you like, through which the 
system calls became accessible. We could quote Dante (or was it Milton) 
above in the documentation: "Abandon hope all ye who enter here ( except 
flash programmers)" :-)

> 4.  But pointers & handles were probably part of the code that put 
> mankind on the moon and guided spacecraft out of our solar system.
I am told by a former colleague who worked on such stuff that they also 
used co-operative multi-tasking because it is more compact, efficient 
and faster than pre-emptive scheduling and thus ideal for 
RAM-constrained well-defined systems...... _provided_ that every 
programmer is aware of and allows for other tasks running on the same 
system. Throw co-operative multi-tasking into the real world where 
everyone necessarily writes for themselves and runtime priorities may 
vary and a pre-emptive approach walks all over it. An example that what 
works for a small team and specific task may be quite different from 
what works for a general population.

> 5.  I have worked primarily independently or with one assistant; so I 
> can only project the dynamics of large group programming projects.  I 
> suspect some of the problems you've investigated may stem from there.
I commented in the previous post on productivity of small teams. Each 
programmer is an individual creative entity so on large projects you 
need protection against the fact that creator A neither knows nor 
probably cares enough what creator B is doing. Hence the importance of 
well defined interfaces, hiding of data and methods and so on, and even 
the need to protect against coding errors by someone whose heart is 
currently down the beach rather than in their software product.

> Rob Cozens
> CCW, Serendipity Software Company
> http://www.oenolog.com/who.htm
>
> "And I, which was two fooles, do so grow three;
> Who are a little wise, the best fooles bee."
>
> from "The Triple Foole" by John Donne (1572-1631)
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>