home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / org / eff / talk / 8222 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  6.9 KB
  1. Path: sparky!uunet!usc!cs.utexas.edu!torn!nott!uotcsi2!revcan!cerianthus!uuisis!tanda!marc
  2. From: marc@tanda.isis.org (Marc Thibault)
  3. Newsgroups: comp.org.eff.talk
  4. Subject: Re: Software as PE
  5. Message-ID: <522322457DN5.61R@tanda.isis.org>
  6. Date: Fri, 01 Jan 93 02:25:31 EST
  7. References: <46.2b2f8ada@ivgate> <bhayden.724605662@teal> <889520164DN5.61R@tanda.isis.org> <1992Dec30.125324.27900@mksol.dseg.ti.com>
  8. Reply-To: marc@tanda.isis.org
  9. Distribution: na
  10. Organization: Thibault & Friends
  11. Lines: 126
  12.  
  13. Gentlefolk,
  14.  
  15.         Fred J asked me to define a real engineer. Here's my shot at
  16.         it and a monologue on the inappropriate use of this term
  17.         as applied to programmers. So that you know my bias, I have
  18.         been engineer, physicist, digital designer, programmer,
  19.         generalist-problem-solver and manager of programmers and
  20.         engineers. I am, for the time being, a designer and integrator
  21.         of systems whose primary function is the automation or
  22.         enhancement of various aspects of human interactivity. If the
  23.         term hadn't been co-opted by ageing programmers, I would
  24.         probably describe myself as a systems analyst. Sometimes, just
  25.         to be obtuse, I do. I still program for relaxation, in several
  26.         languages.
  27.  
  28.         I also want to note that nothing I say here applies to those
  29.         people exploring and defining the frontiers of computation per
  30.         se. The term they misuse is "scientist".
  31.  
  32.         An engineer applies time-tested methods and principles to
  33.         design artifacts integrating materials and components whose
  34.         behavior is well understood, within a specific domain of
  35.         practice. The domain distinction is important; there are
  36.         electronic engineers and mechanical engineers, but the only
  37.         oscilloscope engineers and drafting board engineers are the
  38.         ones who design oscilloscopes and drafting boards for other
  39.         engineers and technicians to use.
  40.  
  41.         Not part of the definition but worth noting: When I buy
  42.         something engineered, it comes with a warranty; When I buy
  43.         software, it comes with a disclaimer.
  44.  
  45.         Before everybody goes ballistic on me, this does allow for
  46.         people who could reasonably describe themselves as financial
  47.         systems engineers or control systems engineers, etc. Their use
  48.         of software as a useful component is incidental even if it's
  49.         99% of the system and they are very good at it. They just
  50.         happen to be saddled with an unreliable medium whose benefits
  51.         outweigh its risks. Calling every good programmer an engineer
  52.         is the equivalent of calling every good musician a composer.
  53.         It's great for his ego but not very accurate, and also
  54.         disappointing if you expect one to write you a theme song.
  55.         It's especially inappropriate if he's the fresh graduate of a
  56.         school that doesn't teach composition.
  57.  
  58.         Software development methods are anything but time-tested;
  59.         they are changing as we speak and none has been consistently
  60.         successful at turning out software that is both reliable and
  61.         efficient. The (relatively) rare program that meets those
  62.         criteria is inevitably the result of intensive hacking by a
  63.         master craftsman whose respect for the paradigm-du-jour would
  64.         be infinitesimal if he or she cared what it was. Nor is the
  65.         behavior of the components well understood. That's why we have
  66.         bugs while engineers make design errors. We can't engineer
  67.         software because we haven't yet figured out _how_. Calling
  68.         programmers software engineers is at best wishful thinking,
  69.         and wishing only makes it so in Disneyland.
  70.  
  71.         It was a software engineer who decided that the brakes on the
  72.         Fokker 100 shouldn't operate if a sensor indicated the wheels
  73.         were up. They were designated part of the "on the ground"
  74.         module. An aircraft systems engineer would have understood the
  75.         difference between the sensor and the fact, recognised that
  76.         applying brakes in midair could do no harm, and saved a few
  77.         pilots a change of underwear.
  78.  
  79.         I don't think this is forever. Wide adoption of standard
  80.         objects will, in time, give the craft of programming a leg up
  81.         on the way to engineering. Engineers have used object-oriented
  82.         techniques since Leonardo, if not before; these are an
  83.         integral part of engineering practice. If that's not obvious,
  84.         get a look at an extended bill of materials (sometime known as
  85.         a "family tree") for some complex electronic or mechanical
  86.         device. I'm not sure, though, that this will happen before you
  87.         can buy software modules packaged in a processor chip with a
  88.         manufacturer's warranty. The PC BIOS industry suggests that
  89.         this is feasable and effective.
  90.  
  91.         It will also require real engineering schools that teach more
  92.         than increasingly complex integer arithmetic. In addition to
  93.         dabbling in a variety of disciplines outside the one in which
  94.         they are _intensively_ trained, engineers become intimately
  95.         familiar with the common and uncommon tools and techniques of
  96.         their trade. For engineering programmers, this means learning
  97.         lots of programming languages, computer and communication
  98.         platforms, protocols, operating systems, editors, design
  99.         standards and (yes, Mabel) paradigms; and to be able to choose
  100.         well which to use for a particular solution in an end-use
  101.         context that they know very well.
  102.  
  103.         No electronic engineer has ever advertised himself as expert
  104.         only with the "Apex Model 5 Logic Analyser". Anyone who
  105.         studied to be an electrical engineer with me can, in
  106.         addition to engineering electrical systems, design a logic
  107.         circuit or machine tool, program any computer, build a barn or
  108.         a cannon, distinguish between a terminal moraine and a
  109.         land-fill site, survey a meadow, and navigate a ship.
  110.  
  111.         You'll know the time has come when recruitment ads for
  112.         programmers (or whatever) don't list programming languages and
  113.         operating systems, but end-use domain expertise instead. You
  114.         know there's still a long way to go when most ads for software
  115.         development _managers_ carry these lists. (You also know that
  116.         you probably don't want the job.)
  117.  
  118.         Cheers,
  119.  
  120.                 Marc
  121.  
  122. ---
  123.  Marc Thibault        |  Automation Architect        |  All we are saying
  124.  marc@tanda.isis.org  |  R.R.1, Oxford Mills,        |  is give global
  125.  CIS:71441,2226       |  Ontario, Canada  K0G 1S0    |  warming a chance.
  126.  NC FreeNet: aa185    |                              |
  127.  
  128. -----BEGIN PGP PUBLIC KEY BLOCK-----
  129. Version: 2.0
  130.  
  131. mQBNAiqxYTkAAAECALfeHYp0yC80s1ScFvJSpj5eSCAO+hihtneFrrn+vuEcSavh
  132. AAUwpIUGyV2N8n+lFTPnnLc42Ms+c8PJUPYKVI8ABRG0I01hcmMgVGhpYmF1bHQg
  133. PG1hcmNAdGFuZGEuaXNpcy5vcmc+
  134. =HLnv
  135. -----END PGP PUBLIC KEY BLOCK-----
  136.  
  137.  
  138.  
  139.