( ESNUG 296 Item 4 ) ---------------------------------------------- [7/23/98]
Subject: (ESNUG 294 #1) Response To Charles Small's "Bad Software Explained"
> The solution to the pressing problem is as drastic as it is obvious once
> you have the facts about human intelligences: Technologists having high
> visual intelligence and possessing visually oriented tools must replace
> the current crop of textually oriented programmers and their antique
> text-based tools.
>
> The difference between the visual and textual methods is dramatic. A
> diagrammatic specification for a complex control program takes only a few
> pages. An engineer blessed with extraordinary visual intelligence can
> easily comprehend the structure of such a system. And equivalent textual
> version of the same program would span many pages grouped in to many
> separate files -- literally incomprehensible by even those having
> extraordinary textual ability.
From: [ Wally Rhines, CEO of Mentor Graphics ]
John,
A really fascinating article from Charles Small!! Thanks for sharing it.
It stimulates a lot of great possibilities for solving a significant basic
problem with software tools.
- Wally Rhines
CEO of Mentor Graphics
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys Field Rep ]
Hi John,
It was an interesting article, but I think that it puts programmers in
much more bad light than they deserve to be. I am not a "programmer" per
se, but with HDL being the norm, I am not sure anymore.
One topic that the author has not touched upon is "How did Einstein (one
of the famous dyslectics featured) communicate his ideas to others?" The
answer is that he used mathematical equations and formal proof to
establish what he could "visulaize". In my eyes, this is nothing but
"poking little groups of characters" into a page. To anyboudy outside
the stratified field of space-time continuum and relativity, it would
appear to be pure gibberish. And, there have been may, who have never
directly communicated with Einstien, but could read the "little groups
of characters" and further his ideas.
Another thing that Small conviently forgets is "What is programming?"
For him, it apprears that programming is simply the mundane and
finger-breaking task of "poking little groups of characters into a text
file". Maybe, you should refer the author to Niklaus Wirths's "Prgram
Development by step wise refinement" (can be dowloaded from ACM
[www.acm.org], classics of the month - december 95)
For me, the actual act of programming is not in "writing" the prgrams,
but in describing what the data structures are and how they interact
with each other when the program runs and the algorithms to be used. The
actual typing of the program _is not programming_. Also, for every
software crash, you could point to 10 "other types of crashes", ranging
from sheer ignorance to oversight to bad design.
Also, the author ignores the large body of "standard practice" availabe
for software development. Any good book on programming practices will
list them (ex. Bjarne Struostrup, C++ programming 3rd Edition - Read the
advice at the end of each chapter. Just that is sufficient to make a
good programmer out of the reader!)
- [ A Synopsys Field Rep ]
---- ---- ---- ---- ---- ---- ----
From: simon@formasic.com (Simon Read)
John,
ESNUG 294 worries me. Software is bad because there is no economic
reward for making it good. The article contains some interesting, old
and thorny points, but also a lot of urban legends.
For a good argument about why software engineering is so hard, check out
"The Mythical Man-Month" (ISBN 0-201-83595-9) by Frederick P. Brooks, Jr.
Chapter 16 of the new edition (the famous "No Silver Bullet" paper) is
especially worthwhile. Brooks was a quite brilliant, and famous hardware
architect for IBM. He then managed the OS/360 software development, where
as he admits, he made a "multimillion dollar mistake". Through his writing
and research since, he has tried to guide others away from the same
mistake[s]. We continue to make those mistakes. I have made them. I have
seen them made. I find his arguments more compelling than those of Larry
Small, perhaps because they are based on more than 30 years of careful
observation and argument.
I cannot recommend Brooks' book highly enough to people who are involved
in 'development in the large' in software, hardware or systems.
- Simon Read
Formal ASICs, Ltd. Annapolis, Maryland
---- ---- ---- ---- ---- ---- ----
From: Jim Cardwell <jim@sd.com>
John,
Thanks! After reading the article in the last ESNUG, now I know why those
hardcore RTL design engineers resist converting to graphical entry tools.
Here's my deduction...
* the article claims visual vs textual intelligence is gender linked:
"At the risk of being Politically Incorrect, it is worth noting that
over a half a standard deviation appears to exist between the average
visual intelligence of males versus females."
* If RTL designers converted to graphical entry tools, males might have
an unfair advantage.
* An unfair advantage for males may reduce the number of female designers.
* So, you guessed it -- RTL designs are coded in text for the women!
Also, since an RTL designer is really half-engineer, half-programmer, I
couldn't help but notice that the article, when duly whittled down, makes
for some great marketing copy for own graphical entry tool! :^)
- Jim Cardwell, Account Manager
Summit Design Campbell, CA
---- ---- ---- ---- ---- ---- ----
From: [ Just Another EDA Developer ]
John,
(Keep me anonymous as I work for an EDA company) while I found the article
on buggy software interesting, I think that it misses the real issue, which
is easily understood by writers and users alike: economics.
What is a bug: typical bugs come about when the software is required to
handle a situation the writer did not consider.
Inspection techniques (Fagan, etc) can find many of these, at a cost.
Testing can find others, again at a cost. Quite simply, the cost of
finding and fixing these bugs is less than the cost of users living
with and working round the bugs, or software suppliers providing a hot fix.
If you look at software for the space shuttle, I would be willing to bet
that the S/W costs at least 10x per line of code to write than EDA s/w.
Similarly, PC s/w such as Windoze and Office probably costs several times
as much to write per line than EDA s/w.
The question is: how many chips would be designed if your P&R s/w cost
10x the current price? How many copies of Windoze '98 would be sold if the
cost were, for example, $400?
Users choose what gives them best value, and best value means living
with bugs. Bug-free s/w would be too expensive in most situations. There
are special cases, (such as the Space Shuttle) where bug free s/w has more
value, and the user is then prepared to pay the cost. EDA applications
are not one of those.
- [ Just Another EDA Developer ]
|
|
