[comp.software-eng] Structured Programming

vfm6066@dsacg3.UUCP (John A. Ebersold) (02/09/89)

Structured programming is currently being discussed in comp.unix.wizards.

To summarize the various comments (with apologies to the original posters):

Structured programming is a way for mediocre programmers to produce good
code; a way to prevent code from deteriorating into a tangled mess, etc.

Also, some programming environments or languages are good certain things
but not good at others.  Forcing a language to do something it doesn't
"naturally" do may be more trouble that it worth.

Pointers are not natural in Fortran - simulating them causes much work.
Other languages that have the notion of procedures without parameters -
simulating the parameters via global variables may impose some structure on
the code - but at what cost?  I did this once but it was NOT fun but I
thought it was worth the trouble.

These types of things are what Frederick Brooks calls the accidents
of software engineering.  In an article in IEEE Computer
Magazine last year Brooks write of the search for the magic bullet that
will slay the software development beast.  He concludes that while many
things can be done no "magic bullet" exists.

No software engineering, program generation environment, etc currently
exists that removes the need for humans to make requirements/design and
design/coding trade when building software.  We don't have a mind reader
that figures out what people REALLY want and writes the code for us.

I pose some questions?

Some people think a good design is more important than the language of
implementation.  A good design is essential but the language is important
also.

Can a good programmer write a good program in a bad language? Yes.

Can a bad programmer write a bad program in a good language? Yes.

Can a bad programmer screw up a good design? Yes.

Real case study (I was the project leader):
In a large software system, a kludge cannot be avoided (the real world is
often that way).

Do you isolate the kludge in one or two modules that
really don't (strictly speaking) need to know about the kludge 
or how to handle it?  The alternative is to put the knowledge of the
kludge in the twenty or so modules other modules.  I choose the former.

Stated another way: A well placed kludge can be considered elegant.

If these things have been discussed before, sorry.

If not, what are your thoughts?

-- 
John A. Ebersold, Unify Corporation @   Defense System Automation Center
osu-cis!dsacg1!dsacg3!vfm6066	     	Columbus, Ohio 		1-614-238-5923
The trouble with the world is that the stupid are cocksure	AV    850-5923
and the intelligent are full of doubt - Bertrand Russell.

campbell@redsox.UUCP (Larry Campbell) (02/12/89)

[I've redirected followups to comp.software-eng, since this has nothing
to do with unix per se.]

In article <4677@pbhyf.PacBell.COM> rsp@pbhyf.PacBell.COM (Steve Price) writes:
}In article <226@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes:
}> Structured Programming
}>is often the buzzword for an attempt to routinize and deskill programming work
}>to reinforce the control of hierarchy over the programming process--separate
}>from and sometimes different from, improving quality.  
}Correct.  This is consistent with the needs of a hierarchical political and
}economic system (which we hackers serve).  Deskilling workers at every level,
}starting at the factory floor and moving up to the middle-level managerial
}class, is the great force now at work in American business.  The skill
}and talents of a few at the top are to control the desired outputs of those
}unskilled workers (or better yet, automated nonhuman systems) below.

The main reason for the desire to deskill programming is that skill is so
scarce.  America is raising generations of idiots.  It is difficult to find
Americans who can write their own native language fluently, let alone write
good code in one or more computer languages.  Skill is scarce but the work
must be done;  one solution is to deskill the work so as to enlarge the pool
of potential workers.

Another solution -- my preferred one -- would be to abolish television and
get really serious about education and intellect.  But that's not likely to
happen any time soon, and even if it did, the improvements would come over
several decades, while structured development can yield results in a year or
two.

One last point -- another goal of structured development (a more encompassing
term than structured programming) which has not yet been mentioned here is to
improve our ability to predict how long a project will take, and thus how
much it will cost.  I believe this is at least as important a goal as that
of deskilling software development.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@bsw.com                        120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02146

wgd@bbt.UUCP (dixon) (02/16/89)

In article <1328@dsacg3.UUCP> vfm6066@dsacg3.UUCP (John A. Ebersold) writes:
>
>Structured programming is currently being discussed in comp.unix.wizards.
>
>To summarize the various comments (with apologies to the original posters):
>
etc.

>Some people think a good design is more important than the language of
>implementation.  A good design is essential but the language is important
>also.
>
>Can a good programmer write a good program in a bad language? Yes.
>
>Can a bad programmer write a bad program in a good language? Yes.
>
>Can a bad programmer screw up a good design? Yes.
>
>Stated another way: A well placed kludge can be considered elegant.
>
>If not, what are your thoughts?
>

I agree wholeheartedly.  At the risk of sounding like *those* people
in comp.unix.wizards (intolerant and with a "hacker" mentality), how
can people in this day and age, with any amount of education, really
feel the way some of them have expressed.  My company would never
knowingly hire someone with those attitudes.  Yes, we feel that there's
no substitute for good design and structured techniques; after all, this
IS and engineering discipline (at least some of us are trying to take
that approach).  I only hope that the "hackers" that are afraid of
"leaping" into the future and using modern SW engineering techniques are
not an example of the calibre of people prevalent on the net (or in the
industry).

Walter Dixon
Broadband Technologies, Inc.
wgd@bbt.uucp
{...}mcnc!rti!bbt!wgd