Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers.rutgers.edu!sri-spam!ames!elroy!jplgodo!wlbr!scgvaxd!trwrb!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: comp.sys.amiga
Subject: Structured Techniques From Hell (was: Electronic Arts bashing)
Message-ID: <1660@cadovax.UUCP>
Date: Sun, 19-Jul-87 20:39:23 EDT
Article-I.D.: cadovax.1660
Posted: Sun Jul 19 20:39:23 1987
Date-Received: Tue, 21-Jul-87 04:33:03 EDT
References: 
Reply-To: keithd@cadovax.UUCP (Keith Doyle)
Organization: Contel Business Systems, Torrance, CA
Lines: 198

In article <893@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes:
>>All the structured design and analysis will not save an idiot.
>
>It *is* set up to save the idiot.

Actually, this is one of the main problems I have with structured
design doctrines/dogmas.  It treats your good programmers like they 
don't know what they are doing.  Virtually any good programmer has 
come to the same conclusions about the design process that structured 
design techniques have.  Buy when managment implements such processes,
it's usually to atone for a history of failed schedules, which in my
opinion is usually due to poor management.  But does management
implement 'structured management techniques'?  No, they pass the
blame down the line, and implement 'structured design techniques' as a
panacea.  And in so doing, they are telling the programmers, "Well,
we don't trust your ability to do a good job without hand-holding,
so we're setting up this procedure to baby-sit you.  And then you
end up with what you payed for, mediocre programmers, producing
mediocre software, because that is what the system is optimized for.

>Do you even know anything about
>the structured design/analysis process?  Part of the process involves
>going over your design THOROUGHLY with your project team.

>You should
>be able to catch all the bugs the user could potentially discover through
>normal use.  Too many packages out there contain bugs that are discovered
>to pathological interference by buffoons.  Structured design eliminates
>most of this.

>In large projects, the documentation that results from following 
>the methodology not only facilitates the delegation of well defined 
>tasks to different people but also makes it easier for future project 
>teams to understand/fix/enhance/modify etc. the code reliably.

Sure, but if you need Yourdon or Marcus to tell you that, or worse, to
setup rigid dogmas to accomplish such, you're already beyond hope.

Management imposition of structured techniques has attacked the *symptom* 
of the problem, not the problem itself.  And what is the problem?
You've lost the ability to keep your programmers inspired and motivated
and to be conciensious toward their job.  If you hadn't they would have
been coming to YOU to tell you they've arrived at new ways of improving
maintainability and bug-free-ness. 

>Look folks, I'm just sick to death of some of the sh*tty code that gets 
>published.  I'm not trying to flame anyone in particular, just immature 
>attitudes towards software design.

So what about the sh*tty code that gets published that was produced with
structured design techniques?  And what good is the most maintainable
code in the world, if the end product isn't worth using?  Or if the
programmers primary goal has been to produce the best looking design
documentation in the world?  The user never sees the design
documentation, and you can't boot the design documentation in his
disk drive.

>When we finally get off of our high chairs and acknowledge that bottom-up-do-
>what-comes-easy-first design just doesn't work for software of considerable
>size, everyone will be a lot better off.  

What I object to, is not the theory of structured design per se, but
the fact that many times, management is shoving it down peoples throat in
an attempt to cover their own ass, because they're completely in the
dark as to how to get a good product out on schedule without somebodys
book telling them what to do.  I'd say they need some techniques to
learn how to manage themselves out of paper bags.  And in particular,
how to motivate people.

I mean, if structured techniques didn't exist, it would be necessary
to invent them.  Because there is an enormous market for a wonderful
warm fuzzy band-aid solution to the 'software problem'.  Never mind how well
it might really work, or if there are other methods that can be used.
Never mind asking the programmers what they think might be good ways
to address the problems, or what shoving ANY technique down peoples 
throat is going to do their motivation and job satisfaction.  Some guy 
over there has written books on the subject that everybodies buying,
so he must know what he's talking about (and never mind that he turns 
around and tries to sell you the software tool to do you the job for 
you for big bucks either).

And then never mind that:

	1) We never have the budget to get the right tools for the job, or
	   really good tools may just be a pipe dream at this time, but
	   are going to impose the dogma anyway without tools.

	2) We don't have the time or money to hold classes for the programmers
	   to tell them how to do all this new stuff that's being expected
	   of them.

	3) We don't care what the programmers think of all this, or what 
	   effects it has on their morale or inspiration, if they don't
	   like it they're all fired.  ("If we base their review on the
	   completeness of the design documentation, they'll get it done")

	4) None of these techniques say anything about the quality of the
	   finished product other than it's maintainablity and bug-free-ness,
	   and tend to make the design documentation everyones primary focus 
	   and responsibility, over and above the true quality and utility of 
	   the finished product.

I tend to subscribe to the less-is-more school of design.  I'd say if the
software is of such a considerable size, it is probably grossly
overdesigned.  The Amiga hardware team, (Miner et al) I would say is
a darn good example of the less-is-more school of hardware design.
It's always easy to make something more complicated.  Making something
less complicated is the hard part.  The most complicated messes I have
ever seen have grown out of structured dogmas, mainly because everyone
is so busy protecting their own ass, and defending their own turf,
trying to make life easier for themselves in a bureaucratic environment.
And due to such priorities, the actual design suffers (good enough for
government work).

Imposing dogmas of structured techniques make management feel they have done 
their job.  Such dogmas are good for below average programming staffs I
suppose.  But I wouldn't know, I've always worked with pretty intelligent
programmers for the most part.

When management comes and asks me how they should do their job, is when
I would expect them to tell me how to do mine.  Do you tell a writer how
to formulate an outline?  Which chapter to write first?  Do you tell an 
artist which colors he should use?  What order he should paint them in?
To produce a detailed design document first?  When you take the 'art' out 
of the 'art of computer programming', is when you take the 'artwork' out 
of the product.  I'm interested in creating works of art, not in camels 
that were supposed to be horses.

If the programmers feel they need to implement specific structured 
techniques to handle a situation, it should be THEIR choice, and THEIR
decision.  After all, it is THEY that you are expecting to do this job.
If you can't get them excited about doing it, all the Youron's and Marco's
in the world won't help you.  You pigenhole your programmers in a box, and
they'll act like square pegs in round holes.  Their interest in the 
project will wane, and you'll lose a lot of them.  At least, you'll
lose the best of them.  You have to keep your good programmers inspired, 
motivated, not optimize your system for idiots.  You should maintain their 
freedom to innovate, to create, if that is what you want them to do.  And 
in my book, that is what you should be wanting them to do.

Any project that is so complicated that you need to implement dogmas
of structured techinques to handle, is probably ALREADY too high-level,
and has not been broken down enough.  It's up to the product managers 
and other managment to learn a little top down design themselves, and 
not foist a ridiculous set of constraints on the design of a product 
which begins to look like the final answer to the worlds problems in one 
single module.

Structured dogmas blame the programmer for everything.  You don't know
how to design your code, noone can support your code, you don't know 
how to document your code, you don't know how to test your code.  And
it could never be that QC or Test or Documentation departments are the
ones that don't know how to do their job, it's up to you to spoon feed 
them with the most outstanding wonderful design documentation in the 
world.  That makes their job easy.  But it does it by making yours (as a 
programmer) more difficult.  As if things weren't complicated enough as
they were, learning 80386 machine language, understanding UNIX and DOS,
keeping up with technology.  And never mind that many programmers aren't 
cut out to be good writers, or good illustrators.  That some of them
may have learned programming because they didn't cut it in english classes.  
That they may be poor communicators.  We can force them to be good 
jack-of-all-trades and do everybodies work for them.  After all, they're
getting paid more than people in those other departments.

You have to give your programmers credit for having some brains.  If you
expect them to act intelligently, they will.  If you treat them like 
children, that's how they're likely to act.  A motivated programmer
will address a comment like 'the support people find it hard to understand
your last program/documentation' by striving to make it better on
the next program.  If he asks for ideas on how to make it better,
certainly a book on structured techniques might be a good suggestion.
Maybe you can get your professional documentation staff (assuming you
have one) involved.  And who knows, he might just come up with a 
solution on his own that works much better for a given situation.  
We'll never know if we don't give him the freedom to be innovative.
But naw, programmers are basically nurds and idiots, we can't expect
them to have any brains.

There are two basic ways you can run a department.  You can take the
people you have, and figure out how to build the best organization you
can around what their abilities are, or you can design the perfect 
organization, and try to fit the people you have into the various 'slots'.
I agree, its much easier for a manager to do the latter.  Otherwise, you 
have to have an organization that is adaptable, as people come and go, and
you will have to do some adapting when that happens.  However, having
an adaptable organization may have other benefits when other things 
change too, like technology, the marketplace, etc.  I prefer an 
organization that tries to make the best use of peoples talents, not 
one that tries to fit everyone into the 'mold' of a perfect programmer.
Unfortunately, until enough management learns of the importance of motivating
people, and ways of doing such, the market for *magic* techniques will
just get larger and larger.

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
#  cadovax!keithd@ucla-locus.arpa  Contel Business Systems 213-323-8170
"Everything should be as simple as possible, but no simpler."
										-Einstein