Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to SE, part 2
Message-ID: <8539@tut.cis.ohio-state.edu>
Date: 18 Mar 88 13:54:17 GMT
References: <2586@Shasta.stanford.edu>
Sender: news@tut.cis.ohio-state.edu
Distribution: na
Lines: 84
In-reply-to: neff@shasta.stanford.edu's message of 17 Mar 88 19:25:31 GMT


neff@shasta.stanford.edu writes:
   there should be a software engineering methodology to determine
   what is the "best" program for the job.  The same should apply to
   operating systems, languages, windowing systems, and other tools.
   Once such a methodology was in place, then it could guide the
   incremental improvement of those programs.

One problem with applying such methodologies to software development
is that there are very few constraints in what one might do.  In EE,
when one is designing a new amplifier (to use the given example), the
design engineer is severely constrained by the hardware
characteristics in which one works.  There are power limitations, the
set of available parts is not infinite and that set has individualized
limitations on what it can do, there are specified tolerances to all
hardware used, even down to and including the percentage accuracy of
the resistors in use.

In software development, there are frequently no such constraints.
One of the reasons that computer programming can be so addictive is
that the medium provides for almost total creativity.  If something
that I want doesn't exist, I can create it - at will, to my own specs,
without adherence to anything external to myself.  The set of software
`parts' is effectively, if not literally, infinite.  The level of
control one can exercise over one's environment is very very large.
Consider the configurability of one's X environment (to use the other
given example); let's see, there are various diddlings one can do to a
existing widget of some sort to change its behavior, and there are
command line options too many to mention to set up those behaviors,
and there is always the .Xdefaults file so one can do away with the
command line options.  My .Xdefaults file is relatively small; it's
only (only!) 2Kb long.  How many programs are affected (that is,
individualized) by the presence of environment variables?  The very
name "environment variable" says a great deal: One is defining one's
entire environment from scratch, to one's own tastes, to suit one's
personality.

Environment definition like this is easy, in fact it's pretty trivial,
for software.  If you don't like something, fine: you've got source,
or you can write new source, or whatever, so you can change it to make
it do what you want.  But for hardware, one has nowhere near the
freedom.  One is always limited by what the available parts are
capable of doing, and so one must design to fit those parts'
constraints.  Software defines its own `parts' on the fly; the only
limitations are in the area of P=?NP and that ilk.

Now, given all that raw creativity, that environment of total control,
of no constraints, one is then faced with the problem of enforcing
discipline.  As a personal opinion, it can't be done.  As others have
been saying, I'm as guilty as anyone - yasee, I've got this version of
the csh which has contracted that dreaded disease, creeping featurism,
and believe me, the condition is terminal; I'm threatening to convert
to ksh when I can find the time to convert my .login and .cshrc files
to .profile and .env.

But more generally, when one is faced with a set of existing software
`parts,' and one finds that they don't do *quite* what one wants, one
is hard-pressed to justify to oneself that one should put up with
what's there.  Again, the opportunity to be creative is too much to
bear for most programmers.  Most importantly, the concept of "it
doesn't do what I want" is a statement of pure personality, with
little or no relation to technical merits.  There are technical merits
to be considered when looking at "what I want," which leads one to
consider the question more as "what *should* I want?"  Hence, we all
have a concept of "clean code" and its inverse "spaghetti code"; we
all know that user interfaces need to have enough capabilities but not
too much as to be unwieldy or to keep one's screen so busy as to cause
one to lose one's place in one's work.  But these are the religious
issues, after all: Just how many GOTOs can you use before a piece of
code becomes "unclean?"  How much implicit type conversion via
parameter passing can one do before lint's complaints are taken
seriously?  How much menu-meta-button magic is OK before they stop
being useful and start getting in the way?  Again, these are, in large
part, statements of personality, and no amount of discussion of
technical merits can overcome it.

UNIX was developed because the OSes available for small PDPs didn't do
what a couple of folks in NJ wanted.  There is an alarming (and,
occasionally, disgusting) amount of philosophy and religion in the
resulting manner in which the UNIX system works.  All because of the
exercise of raw creativity was a Good Thing in most people's minds
when they were faced with a task and a way of approaching it that
didn't fit the mold of the existing software parts.  Similar thoughts
apply to X, Emacs, shells/CommandLineInterpreters, and most any other
software product.