[plt-scheme] Perplexed Programmers

I find the periodic comparisons of software engineering with  
traditional engineering disciplines to be somewhat humorous.  Having  
started off my working life in a large Architecture and Engineering  
firm involved in building airports, water treatment systems, bridges,  
etc., I think there is a bit of a false mystique that these large  
civil works are somehow safe from the overruns, inefficiencies, waste,  
and incompetence found in software projects.

For example:  When I started working in the mid-1990's, it was still a  
novelty for structural designs to be done in 3D.  Drawings were  
instead 2D artifacts shown in plan and section, with pipe, wiring, and  
lighting handled as separate overlays that had the advantage of being  
easy to hand off to individual contractors (lighting, plumbing, etc.,)  
but made it hard to be sure that there were no conflicts between  
different services.

Despite the review process, there were invariably problems once  
construction started and it was discovered that an 8-inch water pipe  
was expected to occupy the same spot of space as a critical structural  
support.  This would result in "change orders" and other on-the-fly  
design changes.  These types of mistakes are so frequent, that there  
is almost always an engineer on-site during construction so that these  
kinds of decisions can be made as quickly as possible.

The process of building a large civil work is so messy, that at the  
end of construction there is always a final phase where the original  
design documents and plans are revised to reflect the myriad of on-the- 
fly changes that had to be incorporated.  These "as-built" drawings  
are then archived for the inevitable future retrofits that will be  
required once the customer decides to add new features, or change the  
original use.

So, I think it's safe to say that many engineering disciplines suffer  
from some form of 'crisis'.  What the traditional fields do have in  
their favor (in my opinion) are the following:

1.  A strong professional society that (along with the government)  
enforces strict educational criteria and proof of minimal competency  
(through licensing) to ensure the work is performed by suitably  
competent practitioners.
2.  Engineering firms have a strong system of apprenticeship.  The  
licensing system doesn't even let you sit for the exam without having  
achieved a certain number of years of experience (and letters from co- 
workers claiming you meet minimal criteria of competency).
3.  Engineering firms have a strong culture of review, in which senior  
engineers review the designs largely created by teams of lower-level  
engineers.  This has the dual effect of passing experience down, as  
well as avoiding errors.

Software engineering has been a bit like the old West, in which  
practically anyone can claim expertise, and there are really no useful  
metrics to gauge qualifications.  At my company, we regularly get  
resumes from people with no business asking someone to pay them for  
development work, and many others who are incredulous that we would  
fail to extend an offer to them (even though they could not answer the  
simple questions we use for our initial screening).

I should also add that another danger with software is how much damage  
one bad developer can wreak on a project.  Because so much of the work  
is 'invisible' to stakeholders, it is very easy for a brittle and  
unstable architecture to pass initial muster (and even meet the  
surface-level requirements usually understood by stakeholders), but  
that falls apart upon first contact with the 'real world'.  The only  
'silver bullet' I have managed to find for this problem are frequent  
reviews, even more frequent communication, and a strong emphasis on  
hiring (and retaining) the right people.

Just my $0.02...

-Brent