Why Projects Fail

[Rob Cozens]

>My point, however, had little to do with whether or not we are 
>discussing powerful programming mechanisms. I said they were and was 
>careful to point out my own familiarity and pleasure at using them. 
>However, my day job includes finding out why $MM projects are off 
>the rails and trying to fix them both technically and commercially, 
>and the techniques you are describing are not industrial strength, 
>are not tolerable in enterprise software development. This is the 
>history of the last 20 to 30 years of software development tools. Go 
>ahead and use them for a stack, debug the hell out of it and you 
>will probably have a very sweet application to offer. Just please 
>don't tell me that this is the the way we should present as a 
>standard set of development tools or techniques.

David,

I'd very much like to learn more about the conclusions you've drawn 
from your investigations.  If other List members are not interested, 
let's take this off list.  However, I think a discussion of what 
you've found could prove helpful to all; so I've started a new thread 
to see if anyone else is interested.

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.

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. 
If the failed projects you have investigated were written in C, I 
would propose that one reason for the project's failure is the 
cryptic nature of C syntax in general.  There are so many variations 
on the same statement grammar that are syntactically correct but mean 
something entirely different (eg: if I remember correctly terminating 
certain statements with a semi-colon changed the meaning entirely) 
it's an ambush waiting to happen.  I think the concepts can be 
implemented in Xtalk in a way that suggests intrinsically the nature 
of the operation.

3.  For moi personally, the goal is to enable direct system calls 
from Xtalk.  Many system calls expect handles or pointers to be 
passed in parameter blocks.  Were it not for that use, I would be 
happy to live without them.  (I guess I'm saying, "if you can get 
system programmers to stop requiring pointers & handles, I can live 
without those features".)

4.  But pointers & handles were probably part of the code that put 
mankind on the moon and guided spacecraft out of our solar 
system...as well as crashing one into Mars because one routine worked 
in metric while another worked in feet & inches.  So there's more 
involved in success or failure of a major programming project then 
whether the programming language gives one access to "programmers 
matches."  Can you share your overall observations & conclusions with 
us?

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.
-- 

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)