NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/software/3269

Text File | 1992-08-20 | 3.7 KB | 76 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!munnari.oz.au!manuel!sserve!ccadfa.cc.adfa.oz.au!ghm
From: [e-mail] (Geoff Miller)
Subject: Re: What is Software Engineering
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Australian Defence Force Academy, Canberra, Australia
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 21 Aug 1992 00:00:36 GMT
Lines: 64

[e-mail] (Steven King, Software Archaeologist) writes:

>[e-mail] (Geoff Miller) publicly declared:
>>[e-mail] (Jeff Musa) writes:
>>>Those that create hack programs, force maintenance programmers
>>>to write hack fixes and these (one on top of another) cause more time to
>>>be spent figuring out and rewritting code just to fix or enhance.
>>
>>In my environment those who create the systems can expect to maintain
>>and develop them, usually working directly with the users.  Self-interest
>>is a powerful incentive to do it right.

>Not necessarily.  *IF* the developers believe that doing it right will
>save them hassle in the long run, then you're right.  But I've worked
>with enough people who have an "Oh, let's just make it work" attitude.
>This is regardless of the fact that they'll have to fix or add on to it
>a year or two later, after they've forgotten what they've done.

It will save them hassles from me.  One of my responsibilities is
management of applications development.  However, I still consider my
point to be largely valid.  A programmer who is working on a day-to-day
basis with the users of a system certainly has a powerful incentive to
get things done quickly, which does lead to a temptation to cut corners,
but equally there is a powerful incentive to do things in a way that
does not cause problems later, because the programmer is seen as
personally responsible.

As far as "hack" programs are concerned, let me state two of my own
policies:

1.   Every non-trivial program must be properly structured and documented.

2.   There is no such thing as a non-trivial program.

>Another dis-incentive to do it right is schedules and management
>buy-in.  I'm currently embattled to convince the managers of a project
>to let us do it right to avoid headaches down the road.  The managers
>want to "just make it work" and don't agree that neat code is
>significantly easier to maintain in the long run.  Mind you, most of
>the managers come from a hardware rather than a software background.

My background is in software  -  in fact, I got into this business as
a user who got more interested in the techniques of computing than
what I was supposed to be using the computing for.  I take your point,
but the battle for "doing it right" is one that I fight with the
users.  BTW, I 'm not clear who you see as being the "managers" of
a project  -  the implication in what you write is that the managers
are computer-people rather than user-people, whereas in my environment
the "managers" of projects are mostly on the user side.  We are developing
applications to support them, but they drive the overall project.

>I agree totally with Jeff Musa.  Hack development forces hack
>maintenance, REGARDLESS of who is developing and who is maintaining, or
>of the fact that the same person may be doing both.

True, but until Jeff introduced the term we weren't talking about
hack development.  If you, and he, are suggesting that rapid prototyping
and evolutionary development are necessarily "hack development" then
I respectfully disagree.

Geoff Miller  ([e-mail])
Deputy Manager Computing Services
Australian Defence Force Academy
Canberra  ACT  2601