From: marc@tanda.isis.org (Marc Thibault)
Newsgroups: comp.org.eff.talk
Subject: Re: Software as PE
Date: Fri, 01 Jan 93 02:25:31 EST
Reply-To: marc@tanda.isis.org
Distribution: na
Organization: Thibault & Friends

Gentlefolk,

        Fred J asked me to define a real engineer. Here's my shot at
        it and a monologue on the inappropriate use of this term
        as applied to programmers. So that you know my bias, I have
        been engineer, physicist, digital designer, programmer,
        generalist-problem-solver and manager of programmers and
        engineers. I am, for the time being, a designer and integrator
        of systems whose primary function is the automation or
        enhancement of various aspects of human interactivity. If the
        term hadn't been co-opted by ageing programmers, I would
        probably describe myself as a systems analyst. Sometimes, just
        to be obtuse, I do. I still program for relaxation, in several
        languages.

        I also want to note that nothing I say here applies to those
        people exploring and defining the frontiers of computation per
        se. The term they misuse is "scientist".

        An engineer applies time-tested methods and principles to
        design artifacts integrating materials and components whose
        behavior is well understood, within a specific domain of
        practice. The domain distinction is important; there are
        electronic engineers and mechanical engineers, but the only
        oscilloscope engineers and drafting board engineers are the
        ones who design oscilloscopes and drafting boards for other
        engineers and technicians to use.

        Not part of the definition but worth noting: When I buy
        something engineered, it comes with a warranty; When I buy
        software, it comes with a disclaimer.

        Before everybody goes ballistic on me, this does allow for
        people who could reasonably describe themselves as financial
        systems engineers or control systems engineers, etc. Their use
        of software as a useful component is incidental even if it's
        99% of the system and they are very good at it. They just
        happen to be saddled with an unreliable medium whose benefits
        outweigh its risks. Calling every good programmer an engineer
        is the equivalent of calling every good musician a composer.
        It's great for his ego but not very accurate, and also
        disappointing if you expect one to write you a theme song.
        It's especially inappropriate if he's the fresh graduate of a
        school that doesn't teach composition.

        Software development methods are anything but time-tested;
        they are changing as we speak and none has been consistently
        successful at turning out software that is both reliable and
        efficient. The (relatively) rare program that meets those
        criteria is inevitably the result of intensive hacking by a
        master craftsman whose respect for the paradigm-du-jour would
        be infinitesimal if he or she cared what it was. Nor is the
        behavior of the components well understood. That's why we have
        bugs while engineers make design errors. We can't engineer
        software because we haven't yet figured out _how_. Calling
        programmers software engineers is at best wishful thinking,
        and wishing only makes it so in Disneyland.

        It was a software engineer who decided that the brakes on the
        Fokker 100 shouldn't operate if a sensor indicated the wheels
        were up. They were designated part of the "on the ground"
        module. An aircraft systems engineer would have understood the
        difference between the sensor and the fact, recognised that
        applying brakes in midair could do no harm, and saved a few
        pilots a change of underwear.

        I don't think this is forever. Wide adoption of standard
        objects will, in time, give the craft of programming a leg up
        on the way to engineering. Engineers have used object-oriented
        techniques since Leonardo, if not before; these are an
        integral part of engineering practice. If that's not obvious,
        get a look at an extended bill of materials (sometime known as
        a "family tree") for some complex electronic or mechanical
        device. I'm not sure, though, that this will happen before you
        can buy software modules packaged in a processor chip with a
        manufacturer's warranty. The PC BIOS industry suggests that
        this is feasable and effective.

        It will also require real engineering schools that teach more
        than increasingly complex integer arithmetic. In addition to
        dabbling in a variety of disciplines outside the one in which
        they are _intensively_ trained, engineers become intimately
        familiar with the common and uncommon tools and techniques of
        their trade. For engineering programmers, this means learning
        lots of programming languages, computer and communication
        platforms, protocols, operating systems, editors, design
        standards and (yes, Mabel) paradigms; and to be able to choose
        well which to use for a particular solution in an end-use
        context that they know very well.

        No electronic engineer has ever advertised himself as expert
        only with the "Apex Model 5 Logic Analyser". Anyone who
        studied to be an electrical engineer with me can, in
        addition to engineering electrical systems, design a logic
        circuit or machine tool, program any computer, build a barn or
        a cannon, distinguish between a terminal moraine and a
        land-fill site, survey a meadow, and navigate a ship.

        You'll know the time has come when recruitment ads for
        programmers (or whatever) don't list programming languages and
        operating systems, but end-use domain expertise instead. You
        know there's still a long way to go when most ads for software
        development _managers_ carry these lists. (You also know that
        you probably don't want the job.)

        Cheers,

                Marc

---
 Marc Thibault        |  Automation Architect        |  All we are saying
 marc@tanda.isis.org  |  R.R.1, Oxford Mills,        |  is give global
 CIS:71441,2226       |  Ontario, Canada  K0G 1S0    |  warming a chance.
 NC FreeNet: aa185    |                              |

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAiqxYTkAAAECALfeHYp0yC80s1ScFvJSpj5eSCAO+hihtneFrrn+vuEcSavh
AAUwpIUGyV2N8n+lFTPnnLc42Ms+c8PJUPYKVI8ABRG0I01hcmMgVGhpYmF1bHQg
PG1hcmNAdGFuZGEuaXNpcy5vcmc+
=HLnv
-----END PGP PUBLIC KEY BLOCK-----