Software Engineering vs. Hacking (was Re: Is General Kind...)

Software Engineering vs. Hacking (was Re: Is General Kind...)

[Robert I. Eachus]

    This forum is really not the right place to discuss the
differences between the hacker culture and criminal "crackers" (or
whatever term you wish to use).  However, the distinction between
hackers and software engineers is very relevant here.

In article <1pirdgINNs48@shelley.u.washington.edu> bketcham@stein2.u.washington
.edu (Benjamin Ketcham) writes:

  > The term "hacker" describes a culture of programmers who program
  > for enjoyment, as well as, often, for work.  The hacker culture
  > espouses the values of robustness and quality in software, and
  > eschews kluge artistry.

   I used to be a hacker, now I am a software engineer...
ROBUSTNESS and quality are not the terms I would use to describe code
written by hackers.  The hacker concept of quality emphasizes
cleverness AND elegance.  Kludgeware is considered bad, but a (single)
kludge used with flair is considered high art.  Software engineers are
more concerned with design.  If the overall design is good, low level
violations of abstraction are considered acceptable if they are needed
to implement the design, and bad otherwise.

  > The term "hacker" has been imprecisely applied by the media to
  > refer to persons who break security on shared computer systems,
  > and/or write and disseminate software viruses.  The true hacker
  > culture has nothing but contempt for these people.

   As I do, and I suspect all of the contributers to comp.lang.ada.

  > A new term has been proposed to describe these security-breakers, to
  > eliminate the current confusion:  "spiders".

   First I heard of this one.

  > Whether or not this term takes hold, it would be nice if we could
  > preserve the correct usage of the term "hacker".  Women and men
  > who call themselves hackers have written some (much) of the
  > highest quality software that exists, and are a driving force
  > behind the evolution of the whole field of software engineering.

   Much is a little much, but some I can agree with.  However, the way
in which hackerdom has driven the evolution of software engineering is
mostly through bad examples.  (Not all or even most code created by
hackers is bad.  But disasters are what provide the impetus for
change.)  Twenty-five years ago, the experts in the field of software
development were artists and there were several examples of software
as works of art: The Algol-W compiler to name just one.  It was
possible to look at these cathedrals of clarity and elegence and
compare them with the many examples of excreta marketed for the same
computers, and realize that something better was possible.

   But the problem to be solved was not how to apply hacker methods to
development of larger software artifacts.  Most of those elegent
artifacts owed their existance, and their maintenance, to a single
exceptional individual.  When someone with a different style touched
the code, it rapidly fell apart.  (Of course, there were a few people
who were excellent imitators, who could maintain the code in the the
style of the originator, but this was rare.)  Chief programmer teams
were created as a way of maximizing the size of a project that could
be created by a single such individual, but even well implemented,
this only doubled or tripled the size of a possible non-kludgeware
system.  Richard Stallman is probably the exception that proves the
rule.

   The alternative, which as you correctly pointed out had exactly the
same roots as the hacker culture (Project MAC and the AI Labs at MIT),
was to develop an environment and a culture in which many programmers
could contribute to a large software system with a single clear and
maintained design.  The development environment on (and for) Multics
was completely opposite in orientation to the hacker ethic, even
though at first it included many of the same individuals.  The
processes of design and implementation were separated, and software
was accepted into the environment (and into Multics) not based on its
implementation, but on its conformance to the overall design concept.

   A good way to think about it is that the hacker culture developed
architects, and the best artists among them, the Christopher Wrens,
and Frank Lloyd Wrights deserve admiration and repect.  Software
engineering on the other hand is more like city planning.  Frank Lloyd
Wright may have been one of the greatest of architects, but most of
his "great" buildings were built in the wilderness because he was
unwilling to adapt his genius to the "whims" of others.

   There was a four-family Frank Lloyd Wright house near where I grew
up.  An excellent and novel solution to the need for low-cost
multifamily housing, many of its features have since been copied
elsewhere.  But when one of the units burned down, there was a major
problem.  The building predated the township zoning laws, and it
violated almost all of them.  Deciding which ones could be waived, and
which would have to be complied with in the reconstruction took the
zoning board most of a year.  (The fire never would have started if
the building met code, but the three other units were undamaged due to
Wright's design...there are no easy answers.  Eventually a compromise
acceptable to everyone, pleasing to no one, was worked out.)

   So although we need and will continue to need architects, in the
future there will be fewer and fewer virgin plots of ground.  We will
all have to be able to work within rules laid out by others.  On the
other hand, we will still need playgrounds where new ideas can be
tried out.  I don't have an easy answer to that problem.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...