[plt-scheme] Perplexed Programmers

Richard Cleis wrote:
> A tenth of a billion dollars was spent on a payroll system that  doesn't 
> work because "complicated, varied job assignments and pay  scales have 
> perplexed computer programmers."
> 
> http://www.latimes.com/news/local/la-me-payroll25aug25,0,630079.story? 
> track=mostviewed-storylevel
> 
> As computers and computer science mature, these stories (and my own  
> trivial experiences) get worse.  What's going wrong?

What's going wrong?  I'd bet it's all embodied in that sentence 
"complicated, varied job assignments and pay scales".  A highly likely 
translation of that is that as yet, there exists no specification that 
fully and accurately describes the required behavior of the system, 
including all the fudging and special-casing that the humans involved in 
the process rely on.  Without such a specification, it is of course 
impossible to produce a working program to automate these processes.

This is a pretty common situation: organizations that perform complex 
processes are not typically sufficiently "self-aware" to communicate the 
details of those processes comprehensively or with any precision.  The 
processes work because of a network of adaptable humans who each have 
pieces of the puzzle.  If one imagines an organization as a brain, the 
process-following behavior is essentially an unconscious one, akin to 
the classic example of a dog catching a ball.

Imagine a dog approaching a consulting firm to automate its 
ball-catching behavior.  The dog can't tell the consultants the 
equations governing the motion of the ball, or how it responds to that 
motion.  The consultants have to figure that out, and they have to do so 
from the "outside", since they don't do ball-catching themselves.

There's no easy way to test specifications once they're developed, 
either.  Perhaps the most reliable approach so far is to develop systems 
incrementally, but for some complex systems that's not very practical 
("irreducable complexity").

Related to all this is overambitiousness and the resulting 
overspecification.  Both managers and programmers, when specifying and 
designing an automated system, have a tendency to want to automate it 
down to the last detail.  Programmers want this for a variety of reasons 
which probably don't need to be explained here.  Managers want it 
because of the wet dream of systems that minimize the human element, so 
that all you need are some cheap keypunching labor to keep the system 
running.

But implicit in this overspecification is a tendency to underestimate 
the degree to which human-run processes adapt to changes as a matter of 
course.  Again, this adaptation happens "unconsciously": individuals 
respond to special cases and do what's necessary to keep the process 
running.  The organization as a whole isn't "aware" of all of these 
adaptations, e.g. they're not all documented (ISO 9001, anyone?)  This 
adaptiveness is damaged when a rigid computerized system is imposed: 
essentially, the system's specification changes regularly, which leads 
to abuses of the system to work around the things it cannot handle, 
which begins a cycle of problems: now the group is working around the 
automated system, and you're dealing with something bigger than mere 
bugs in the software.

This is the exact opposite of the socialware approach of exploiting 
group intelligence: it explicitly tries to take as many decisions as 
possible out of the hands of the group.  The systems that fail are not 
as adaptable as the groups that they're supposed to semi-replace.

All of the above is just one dimension of the problem.  There are many 
others.  An oft-discussed one which tends to come into play in this sort 
  of development are the typical corporate approaches to project 
management, which don't apply well to software development.  Stories 
about this abound on the web, e.g. Reg Braithwaite's recent article 
about software not being made of bricks: 
http://weblog.raganwald.com/2007/08/bricks.html

> Oh, never mind.  This forum is for cheerier topics... like what kind  of 
> Mean Scheme Machine could be built for the 37M$ that will be spent  on 
> fixing the 95M$ problem.

The limitations of programming languages and software tools are another 
big factor.  The response to this is a high-speed, never-ending cycle of 
"upgrades" which means that any chosen set of tools forms an incredibly 
unstable platform, and regular upgrades and the resulting ripple effects 
are all but essential.

In any case, silver bullets don't help if you're shooting at the wrong 
monster.

Anton