No Silver Bullet
Daks Pandya
I am writting a paper om challenging Fred Brooks and his notion of 'No
Silver Bullet' any idea's or leads for further info. will be greatly
appreciated.
kind regards,
Daks Pandya
+----------------------------------------------+
URL: http://www.gre.ac.uk/~pd371
+==============================================+
Charles E. Matthews
Daks Pandya wrote:
>
> I am writting a paper om challenging Fred Brooks and his notion of 'No
> Silver Bullet' any idea's or leads for further info. will be greatly
> appreciated.
Nice troll. OK, I'll bite. What is your idea which will be the silver
bullet to slay the demons of cost overruns and poor software quality?
Don't you think that it is a tad bit of an oversight to say you have "the
answer" but then don't give it?
Regards,
Chuck
______________________________________________________________________
Charles E. Matthews
Software consulting in knowledge
Synergistic Technologies based systems and object oriented
chu...@infonet.isl.net analysis and design
Onorio Catenacci
Daks Pandya wrote:
>
> I am writting a paper om challenging Fred Brooks and his notion of 'No
> Silver Bullet' any idea's or leads for further info. will be greatly
> appreciated.
it. There was a famous author (name escapes me right now). He was asked
what was his secret to writing well. He replied that if there were a
secret to good writing he'd like to know it so he could use it himself.
I feel the same way about software development. If you find a silver
bullet, please post the information. I'd love to hear about it.
--
Onorio
Note: Any opinions expressed are solely
my own and <the rest of the standard disclaimer.>
+----------------------------------------+
| Pioneers may get there first but they |
|also get all the arrows in their backs. |
+----------------------------------------+
Andy Brice
Daks Pandya wrote:
>
> I am writting a paper om challenging Fred Brooks and his notion of 'No
> Silver Bullet' any idea's or leads for further info. will be greatly
> appreciated.
>
Fred Brooks was right (about this and other things)!
Andy Brice
Onorio Catenacci
Charles E. Matthews wrote:
>
> Daks Pandya wrote:
> >
> > I am writting a paper om challenging Fred Brooks and his notion of 'No
> > Silver Bullet' any idea's or leads for further info. will be greatly
> > appreciated.
>
> bullet to slay the demons of cost overruns and poor software quality?
>
> Don't you think that it is a tad bit of an oversight to say you have "the
> answer" but then don't give it?
PMFJI, but I don't think he's saying that he has the answer. I think he's
saying that he's trying to challenge the idea and wants to find
information challenging the idea.
Just my $.02
Gene Wirchenko
"Charles E. Matthews" <chu...@infonet.isl.net> wrote:
>Daks Pandya wrote:
>>
>> I am writting a paper om challenging Fred Brooks and his notion of 'No
>> Silver Bullet' any idea's or leads for further info. will be greatly
>> appreciated.
>Nice troll. OK, I'll bite. What is your idea which will be the silver
>bullet to slay the demons of cost overruns and poor software quality?
>Don't you think that it is a tad bit of an oversight to say you have "the
>answer" but then don't give it?
No more than it is to claim that he stated he had the answer when
he made no such statement. Perhaps, he is exploring the possibilities
of a challenge to it. It is a good idea to review concepts from time
to time to be sure that they are still valid.
Sincerely,
Gene Wirchenko
C Pronunciation Guide:
y=x++; "wye equals ex plus plus semicolon"
x=x++; "ex equals ex doublecross semicolon"
Tom Royer
> I am writting a paper om challenging Fred Brooks and his notion of 'No
> Silver Bullet' any idea's or leads for further info. will be greatly
> appreciated.
>
>
> kind regards,
>
> Daks Pandya
> +----------------------------------------------+
> URL: http://www.gre.ac.uk/~pd371
> +==============================================+
Good luck, you're really going to need it.
--
Tom Royer
"If you're not free to fail, you're not free." - - Gene Burns
MITRE might be better off if I spoke for them, but, unfortunately for them, they've elected not to find out.
Dave Cline
Andy Brice wrote:
> Fred Brooks was right (about this and other things)!
I'm sure that Brooks was and is right about many things, but
he has an unfortunate ability coin aphorisms which "one minute
software managers" use to substitute for critical thinking.
All too often requests for additional resources are dismissed
with "adding people to a late software project makes it later".
Requests for tooling are dismissed by "there's no silver bullet".
Brooks' slogans are rules of thumb; they aren't immutable laws
of the universe. You must understand the reasoning and the
context.
--
Dave Cline dcl...@cup.hp.com
The Hawthorne effect is your friend
Gary Capell
"Charles E. Matthews" <chu...@infonet.isl.net> writes:
:Daks Pandya wrote:
:> I am writting a paper om challenging Fred Brooks and his notion of 'No
:> Silver Bullet' any idea's or leads for further info. will be greatly
:> appreciated.
:Nice troll. OK, I'll bite. What is your idea which will be the silver
:bullet to slay the demons of cost overruns and poor software quality?
:Don't you think that it is a tad bit of an oversight to say you have "the
:answer" but then don't give it?
It wouldn't fit in the margin of his original post.
Peter Murray
Charles E. Matthews (chu...@infonet.isl.net) wrote:
: Daks Pandya wrote:
: >
: > I am writting a paper om challenging Fred Brooks and his notion of 'No
: > Silver Bullet' any idea's or leads for further info. will be greatly
: > appreciated.
: Nice troll. OK, I'll bite. What is your idea which will be the silver
: bullet to slay the demons of cost overruns and poor software quality?
Maybe he has a new Space-Age, Carbon Fibre bullet?
Andy Brice
Andy Brice wrote:
>
> Daks Pandya wrote:
> >
> > I am writting a paper om challenging Fred Brooks and his notion of 'No
> > Silver Bullet' any idea's or leads for further info. will be greatly
> > appreciated.
> >
Seeing as you aren't getting much help here, below are a few
things that were touted as silver bullets, but turned out (or
will turn out!) not to be :
case tools
structured programming
cobol('everyone will be able to do their own programming'!)
3 GLs
4 GLs
software re-use
object oriented this and that
Java?
What did I miss?
To be fair, the hyped claims were usually made by the salesmen,
not by the propellor heads.
Andy B.
|--------------------------------------------|
| \ Andy Brice |
| \\ abr...@quantisci.co.uk |
| \\ |
| \\ QuantiSci Ltd. |
| \\ Chiltern house |
| ///////\\ 45 Station Road |
| ////// \\ Henley,Oxfordshire |
| // \\ RG9 1AT,UK |
| // \\ |
| \\\\\\\\\\\\\\\\\ |
| \\\\\\\\\\\\\\\\ Fax:+44 1491 576916 |
| http://www.quantisci.co.uk/ |
|____________________________________________|
David Alex Lamb
In article <3280C3...@infonet.isl.net>,
Charles E. Matthews <chu...@infonet.isl.net> wrote:
>Daks Pandya wrote:
>>
>> I am writting a paper om challenging Fred Brooks and his notion of 'No
>> Silver Bullet' any idea's or leads for further info. will be greatly
>> appreciated.
>answer" but then don't give it?
The issue worth thinking about is the implication that there *can't* be any
"silver bullets" (not just that there aren't any right now). Personally, my
money's on Fred. Especially since, if we find something that dramatically
improves productivity, we crank up the level of complexity of the systems we
design. Nevertheless, focusing on the things he listed as inherent problems
and seeing if we can find ways to solve them is probably worth doing.
For example, didn't the article talk about architecture being "invisible"?
And aren't there a lot of people working on architectural notations these
days?
--
http://www.qucis.queensu.ca/home/dalamb/
Alan Hecht
In article <328070...@gre.ac.uk>, Daks Pandya <pd...@gre.ac.uk> wrote:
>I am writting a paper om challenging Fred Brooks and his notion of 'No
>Silver Bullet' any idea's or leads for further info. will be greatly
>appreciated.
Well, for starters, Brad Cox wrote a paper challenging the notion. You
can get it at http://www.virtualschool.edu/mon/Cox/AmProTTEF.html.
There was also an article that appeared in the Jan. 1992 issue of IEEE
Computer. I don't remember the name or author off hand.
Dr. Brooks has also written a follow up to his paper which appears in the
2nd ed. of 'The Mythical Man Month' which addresses the challenges published.
--
Alan Hecht | "Analogy is always unreliable as a guide to understanding,
al...@crl.com | but trying to find a useful analogy can be illuminating."
|
| Bjarne Stroustrup
Dave Ceely
In article <3280B9...@quantisci.co.uk>,
on Wed, 06 Nov 1996 16:16:27 +0000,
Andy Brice <Andy> writes:
>Daks Pandya wrote:
>>
>> I am writting a paper om challenging Fred Brooks and his notion of 'No
>> Silver Bullet' any idea's or leads for further info. will be greatly
>> appreciated.
>>
I agree with others that Fred Brooks was right, but would like to add a
little OPINIONated information as to why I think so. Many fall into the
trap of thinking that software development is ONE problem, and with that
as an assumption look for THE answer. Not so, is my position. There
are good reasons for doing rather undiciplined development (say algorithm
prototyping) and good reasons for doing extremely diciplined development
of new software (life critical medical devices, manned space vehicle
command and control). Processes and methods for these might be so different
as to be unrecognizable. These days we are integrating very large complex
systems using reusable architectures and assets (both commercial, off-the-shelf
and proprietary reuse.) Some complex commercial systems are being built
using mostly off-the-shelf components augmented by generated code and maybe
a little bit of glueware. The aforegoing expresses a tiny fraction of the
variety of domains and methods currently recognized to apply to software
system implementation. If you will admit that this is true, how can you
assert a single solution broad enough to cover all of this ground and
still be thought of as a silver bullet?
Dave Ceely
Lockheed Martin Federal Systems
Opinions expressed are inclusively my own
and may not be shared by my employer
Those not in power WANT change and
those IN power ...
Dion Dock
> > I am writting a paper om challenging Fred Brooks and his notion of 'No
> > Silver Bullet' any idea's or leads for further info. will be greatly
> > appreciated.
I can think of two examples: GUI builders and compilers.
It is pretty obvious that compilers bring order of magnitude improvements
in productivity and robustness.
Back in the day when GUIs
first came out, you had to call functions, pass in parameters (window
width in pixels, etc.), with lots of room for errors. Now there are
commertial GUI builders that can automatically generate code for you.
So you could answer that a GUI builder is a "silver bullet" for GUI design.
But Brook's arguement was there is no silver bullet for software design
in general, which is still valid.
-dion
George X. Kambic Ph.D.
Daks Pandya wrote:
>
> I am writting a paper om challenging Fred Brooks and his notion of 'No
> Silver Bullet' any idea's or leads for further info. will be greatly
> appreciated.
I am confused. I have just read a bunch of replies challenging Mr.
Pandya's paper, that he is trolling, that he needs a lot of help,
good luck, etc. What the heck is going on here? Why shouldn't
Brook's be challenged. I like a lot of what he says, but that
should never stop the endeavour of reevaluation that is part of
science and engineering. The replies that I read struck me as
treating MMM as "Truth." Ummm.....if so, why has anything been
written on SE since then? Or is everything just commentary.
This is not the first time that I have seen this happen, and
should not be the last. If Brooks stands up to the test, great,
we have all learned something. If MMM does not, then we have
benefitted even more.
Take your best shot, Mr. Pandya. It will be interesting.
George Kambic
Richie Bielak
Tom Royer wrote:
[...]
>
> Good luck, you're really going to need it.
>
> --
> Tom Royer
The readers of this thread should check out the book by Brad Cox
called "Superdistribution: Objects As Property on the Electronic
Frontier". One of the reasons Brad Cox wrote the book was as
as challenge to the "No Silver Bullet" paper by Fred Brooks.
Also the latest edition of "Mythical Man Month" includes
Brook's responses to such challenges.
...richie
--
* ric...@netlabs.net - at home | Richie Bielak *
* ric...@calfp.com - at work | *
* Home page: http://www.netlabs.net/hp/richieb *
* "The network is not the computer, the network is the bus." (me) *
Tom J
I presume that a silver bullet would have to be a silver bullet for all
or most types of software projects.
The reason there is no silver bullet for writing software is
the same as the reasons that they is no silver bullet for writing books;
there is too much variety, the demands in one type are completely
different with the demands in another. A silver bullet for client/server
SQL applications (VC++) will not work for scientific real-time data
acquisition systems. A silver bullet for game programming (Brenda Laurel
and Ed Yourdon both point to games for lessons for the rest of us)
will not work for payroll systems.
--
Tom Janzen - t...@world.std.com USA Distributed Real-Time Data Acquisition S/W
for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio
http://world.std.com/~tej
tada...@aol.com
Take a look at the paper "Biting the Silver Bullet" by David Harel (_IEEE
Computer_, January 1992). It's a response to Brook's position.
\
tada...@aol.com
Perhaps Brook's paper is mistitled. The natural
meaning of "No Silver Bullet" is that no one
ingredient of the software process is so important
that all others can be neglected. Brook's thesis
is that no ingredient of the software process
addresses the essence of the problem. Perhaps
"No Cure for the Common Cold" would have been
a better title.
Actually, Brook's seems to imply that an ingredient
that addressed the essense could be a silver bullet.
That is a dubious proposition.
Brian A. Batke
In article <19961108071...@ladder01.news.aol.com>, tada...@aol.com writes:
|> ... Brook's thesis
|> is that no ingredient of the software process
I think there is a "Silver Bullet". I can't take credit for this, as I learned
it from my mentor and friend, Jerry Weinberg. It goes like this:
Behind every software engineering problem lies the beating heart
of a software engineer.
--
Brian...@ab.com
Allen-Bradley Co., Mayfield Hts, Ohio
tada...@aol.com
You could write a paper called
"No Werewolf, Either". Does
software development really have an essense to
be addressed? Did Brooks identify this essense.
If the so-called essence is addressed will that
really solve the software crisis?
What is the essence of cooking, of making cars?
Seems to me that a lot of problems must be
solved, not just the one of figuring out what
the customer wants.
Jeffrey McArthur
WARNING: the following message is supposed to taken humorously.
"There are few problems in life that cannot be solved by sufficient
application of high explosives."
----
Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
a.k.a. Jeffrey McArthur email: j_mca...@bix.com
phone: (301) 306-5188 jef...@connext.net
home: (410) 290-6935 JMca...@gnn.com
The opinions expressed are mine. They do not reflect the opinions
of my employer. My access to the Internet is NOT paid for by my
employer. My access to the Internet is on my own time at my own
expense.
pted...@aol.com
I like your list of the failing silver bullets.
In article <3281C3...@quantisci.co.uk>, Andy Brice
<abr...@quantisci.co.uk> writes:
>case tools
>structured programming
>cobol('everyone will be able to do their own programming'!)
>3 GLs
>4 GLs
>software re-use
>object oriented this and that
>Java?
>
The problems we encounter within systems need to be approached
not just with the quick fix of (the above). Much work needs to
be performed to satisfy rapid implementation of systems.
Corporations establish budgets that prohibit satisfying this
problem and opt for solutions like the above. The problem that
ensues is adequately described the the book "The Fifth
Discipline" from Peter Senge.
Paul Tedesco
Cognitor, Inc.
The web page :
http://members.aol.com/PTedesco/cognitor.html
describes AI, Software Engineering, Business Process Engineering,
Regenerative Engineering, and reuse combined.
James McKim
In article <55ri7v$h...@knot.queensu.ca> dal...@qucis.queensu.ca (David Alex Lamb) writes:
>In article <3280C3...@infonet.isl.net>,
>Charles E. Matthews <chu...@infonet.isl.net> wrote:
>>>
>>> I am writting a paper om challenging Fred Brooks and his notion of 'No
>>> Silver Bullet' any idea's or leads for further info. will be greatly
>>> appreciated.
>>answer" but then don't give it?
>
>The issue worth thinking about is the implication that there *can't* be any
>"silver bullets" (not just that there aren't any right now). Personally, my
>money's on Fred. Especially since, if we find something that dramatically
>improves productivity, we crank up the level of complexity of the systems we
>design. Nevertheless, focusing on the things he listed as inherent problems
>and seeing if we can find ways to solve them is probably worth doing.
People tend to overlook a rather central issue when referring to Brooks's
paper. His actual thesis was that there would be no silver bullet within
_10_ years: "But, as we look to the horizon of a decade hence, we see no
silver bullet." While the CACM version of the paper was published in 1987,
the original version (read the fine print in CACM) was published in 1986.
Therefore Daks Pandya will have great difficulty challenging Brooks's
_stated_ thesis, unless there is a major breakthrough in the next few
weeks.
Of course the issue of whether there can _ever_ be a silver bullet is
still interesting. Richie Bielak mentioned Brad Cox's work, an early
version of which can be found in "Planning the Industrial Revolution" in
the November, 1990 issue of IEEE Software. I believe David Harel also
wrote a response to Brooks, but cannot immediately lay my hands on the
reference.
Hope this helps,
-- Jim
[..]
--
*------------------------------------------------------------------------------*
Jim McKim (860)-548-2458 Teachers affect eternity. They can never tell
Internet: j...@hgc.edu where their influence stops.
Bob Kettig
In article <55vrs8$2...@news1.cle.ab.com> Brian A. Batke,
b...@cle.ab.com writes:
>
> I think there is a "Silver Bullet". I can't take credit for this, as I learned
> it from my mentor and friend, Jerry Weinberg. It goes like this:
>
> Behind every software engineering problem lies the beating heart
> of a software engineer.
But as the foolball coach says:
You can't "play with heart" on a math test. :-)
- Bob
Bob Kettig
In article <55vrs8$2...@news1.cle.ab.com> Brian A. Batke,
b...@cle.ab.com writes:
>
> I think there is a "Silver Bullet". I can't take credit for this, as I
> learned it from my mentor and friend, Jerry Weinberg. It goes like
> this:
> Behind every software engineering problem lies the beating heart
> of a software engineer.
Guy Rixon
David Alex Lamb wrote:
>
> In article <3280C3...@infonet.isl.net>,
> Charles E. Matthews <chu...@infonet.isl.net> wrote:
>
> The issue worth thinking about is the implication that there *can't* be any
> "silver bullets" (not just that there aren't any right now). Personally, my
> money's on Fred. Especially since, if we find something that dramatically
> improves productivity, we crank up the level of complexity of the systems we
As the scope of the systems keeps increasing, it's hard to see how a
single tool or technique could solve the compelexity problem for more
than a few years. If we want to get out of the tar-pit permanently,
we're going to need some really radical (and currently unfeasible) like
replacing digital, sequential processors with something more suited to
good engineering or reinventing ourselves as as less falible people (or
genuinely intelligent,
self-improving expert systems that make like less falible people).
However, I don't think that the scope _is_ going to increase
indefinitely. Back in 1980, any system that could be produced at low
risk was probably to trivial for general use and a useful system was
probably too hard. Any improvement in process had immediately to be
submerged by bigger systems because the existing systems were so
inadequate. Nowadays, there are many useful systems (especially the
smaller embedded ones) that are quite managable with existing tools.
The complexity of useful systems is limited by the complexity of the
human affairs that they support, and we aren't evolving our society fast
enough to raise that complexity limit much.
Over the next ten years, I predict that process, tools, and techniques
will gradually catch up with the sort of jobs we routinely need to
undertake. So, no silver bullets, but we may yet get the werewolf
house-trained and turn him vegetarian.
--
Guy Rixon, g...@ast.cam.ac.uk
Software Engineering Group, Tel: +44-1223-374000
Royal Greenwich Observatory Fax: +44-1223-374700
Bob Kettig
In article <3289DA...@ast.cam.ac.uk> Guy Rixon,
g...@ast.cam.ac.uk writes:
> ...and we aren't evolving our society fast enough to raise that
> complexity limit much...
You might find the Tofflers' books (Future Shock, Third Wave,
etc) interesting, if you haven't already. On the one hand,
they say that the information revolution will completely
transform society, just as the agricultural and industrial
revolutions did. On the other hand, each revolution
eventually ends, followed by relative stability. So you are
predicting that the end has just about come. I hope you're
right.
- Bob
Andy Brice
tada...@aol.com wrote:
>
> Perhaps Brook's paper is mistitled. The natural
> meaning of "No Silver Bullet" is that no one
> ingredient of the software process is so important
> is that no ingredient of the software process
> "No Cure for the Common Cold" would have been
A 'silver bullet' is a mythical cure for a mythical werewolf. As
I remember Brooks' book (I read it some years ago) he was saying
that software engineering is difficult and no magic technique
(such as case tools etc) is going to stop it being difficult.
Hence there is no silver bullet to kill the werewolf.
I think silver bullet is rather a good etrm in the context.
Andy B.
Bill Bolton
Andy Brice <abr...@quantisci.co.uk> wrote:
> A 'silver bullet' is a mythical cure for a mythical werewolf.
Ah, so that's what the Lone Ranger was after....
Cheers,
Bill
____________________________________________________________
Bill Bolton billb...@acslink.net.au
Sydney, Australia
Tom Welsh
It seems to me that in saying "There is no silver bullet" Brooks was
stating the obvious. But it needs restating EVERY DAY because we
fallible human beings are always prone to wishful thinking. We would
LOVE to find some magic box that would take all responsibility from our
shoulders. (The genie in the bottle was an early parable about the
dangers of delegating too much authority this way).
Brooks may have said it 25 years ago, but it still needs repeating. I
have given talks where I insisted that "there is no silver bullet" and
the audience walked out nodding sagely and agreeing. Half an hour later
many of them were marvelling over some new techno-fix they had found...
One other point. Of course there is no silver bullet in the sense that
nothing is BY ITSELF sufficient to solve all our software development
problems. But it is interesting to see how people then rush to the
opposite extreme. Because 4GLs, expert systems, CASE, objects etc. are
not "silver bullets", the press labels them as "failures". This is
dangerous rubbish. Ten years after the "collapse" of expert systems,
hundreds of business-critical applications around the world depend on
rule-based software to give them their edge. All these new ideas go
through the same cycle: obscurity, discovery, overexcitement,
reassessment, rejection, and then an indefinite period of quiet
usefulness.
--
Tom Welsh
Bob Kettig
In article <qCTmCJAG...@draco.demon.co.uk> Tom Welsh,
T...@draco.demon.co.uk writes:
> ...
> All these new ideas go through the same cycle: obscurity,
> discovery, overexcitement, reassessment, rejection, and
> then an indefinite period of quiet usefulness.
Well said Tom.
Of course not everyone jumps on the bandwagon and jumps back
off. Many people just wait patiently for the period of quiet
usefulness.
"objects", I assume, have reached the overexcitement phase
(yes?). We should soon be looking forward to reassessment and
rejection, triggered, I suppose, by the usual project delays,
quality crises, and cost-overruns.
- Bob
psgo...@aol.com
Your request for discussion/information about Silver Bullets fails to
describe any problem at which a Bullet might be aimed.
State the problem, bullets will fly. Some will look silver. If any are,
the news will spread. If they can be painted as silver, they will be
hyped.
Someone mentioned "silver bullets for software quality." Most of the
bullets I've seemed aimed at quality were just that -- bullets, as in
"projectiles" whose purpose was to make a hole in something. If you want
quality in software development, you have to adopt quality practices.
Few developers in mainstream software are willing to undergo that level of
discipline.
Maybe discipline is the silver bullet.
Andy Brice
Guy Rixon wrote:
..
> The complexity of useful systems is limited by the complexity of the
> enough to raise that complexity limit much....
Not sure I agree with this point. Systems seem to be getting more and more
complex at quite a rate, at least keeping pace with our ability to handle
them. In fact the introduction of computers generally (always?) makes a system
MORE complex.
Andy Brice
Guy Rixon
Some systems do get more and more involved, sure. But there are already
a lot that don't. Word processors, having long ago evolved past the
point where most users could learn and use all the features, seem to me
to be stabalizing. The software in mass-market consumer goods like TVs
may be gaining in complexity but doesn't seem to be tracking the leading
edge so closely that there are regular disasters (anybody hear about
mass recalls of consumer goods because of duff firmware?).
The programs and systems that seem to be working out best are those that
assist a user in an interactive task: they are analogous to hand-held
power tools and tend to be limited in complexity by what a person can do
in real time.
The systems that seem to me to be most risky, and the ones for which
complexity rises fastest, are those that try to automate people out of a
process. These are to the simpler interactive systems as robotic machine
tools are to hand-held power tools. Because they are intended to be
better (faster, safer, more flexible etc) that the human workers they
replace, they don't have the same complexity limits. However, even
these systems are limited by the ability of the customer and supplier to
dream up new features.
Mark McWhinney
The difference is that werewolves who are created by unseen external
forces attack their unsuspecting victims without warning. In software
development, we know what creates the werewolves, when they are going to
attack, and what they are going to do.
Maybe a better one is "We have met the enemy, and he is us"
Mark McWhinney
Nick Thurn
Guy Rixon (g...@ast.cam.ac.uk) wrote:
>
> Some systems do get more and more involved, sure. But there are already
> a lot that don't. Word processors, having long ago evolved past the
> point where most users could learn and use all the features, seem to me
> to be stabalizing.
>
This is a good point. The "Office Suite" type products seem to be heading for
the tag "commodity" and entering the area of diminishing returns for most
users. IMO we will see see more of this in the next few years, possibly
with the standardisation of such applications (and I do mean standardisation
not monopolisation :)
> The software in mass-market consumer goods like TVs
> may be gaining in complexity but doesn't seem to be tracking the leading
> edge so closely that there are regular disasters (anybody hear about
> mass recalls of consumer goods because of duff firmware?).
>
Exactly! The gee whizz factor has worn off, remember Digital watches and
programmable calculators in the 70's. Who cares anymore?
> The systems that seem to me to be most risky, and the ones for which
> complexity rises fastest, are those that try to automate people out of a
> process.
>
Aren't you forgetting all the secretarys and clerks thrown out of work
by non-risky PC Office products?
> These are to the simpler interactive systems as robotic machine
> tools are to hand-held power tools. Because they are intended to be
> better (faster, safer, more flexible etc) that the human workers they
> replace, they don't have the same complexity limits. However, even
> these systems are limited by the ability of the customer and supplier to
> dream up new features.
>
I don't agree here. CAD/CAM (this is what you are talking about?) is well
entrenched. Are you thinking of the Denver airport type project?
cheers
Nick (my opinions only)
Guy Rixon
Nick Thurn wrote:
>
> Guy Rixon (g...@ast.cam.ac.uk) wrote:
> > The systems that seem to me to be most risky, and the ones for which
> > complexity rises fastest, are those that try to automate people out of a
> > process.
> >
> Aren't you forgetting all the secretarys and clerks thrown out of work
> by non-risky PC Office products?
I meant the risk of the development projects going wrong, not the risk
of
social collapse (that happens when the software engineers get it _right_
;-( ).
> > These are to the simpler interactive systems as robotic machine
> > tools are to hand-held power tools. Because they are intended to be
> > better (faster, safer, more flexible etc) that the human workers they
> > replace, they don't have the same complexity limits. However, even
> > these systems are limited by the ability of the customer and supplier to
> > dream up new features.
> >
> I don't agree here. CAD/CAM (this is what you are talking about?) is well
> entrenched. Are you thinking of the Denver airport type project?
Sorry, I didn't explain that very well. Yes, I agree that CAD/CAM is a
productive and well-sorted field of engineering; I was using it as a
metaphor for highly complex and automatced systems in general. Anyway,
one might expect problems with a new CAM cell that would never occur in
a process using hand-held tools. My point was that software that tries
to do things without human guidance may end up having to be as
sophisticated as the person it replaces and it's this use (misuse?) of
machine capabilities that leads to the most complex systems.
Nick Thurn
Guy Rixon (g...@ast.cam.ac.uk) wrote:
> > > These are to the simpler interactive systems as robotic machine
> > > tools are to hand-held power tools. Because they are intended to be
> > > better (faster, safer, more flexible etc) that the human workers they
> > > replace, they don't have the same complexity limits. However, even
> > > these systems are limited by the ability of the customer and supplier to
> > > dream up new features.
> > >
> > I don't agree here. CAD/CAM (this is what you are talking about?) is well
> > entrenched. Are you thinking of the Denver airport type project?
>
> Sorry, I didn't explain that very well. Yes, I agree that CAD/CAM is a
> productive and well-sorted field of engineering; I was using it as a
> metaphor for highly complex and automatced systems in general. Anyway,
> one might expect problems with a new CAM cell that would never occur in
> a process using hand-held tools. My point was that software that tries
> to do things without human guidance may end up having to be as
> sophisticated as the person it replaces and it's this use (misuse?) of
> machine capabilities that leads to the most complex systems.
>
Remember "the crash" when all the programmed trading apps followed
each other into the ground :)
cheers
Nick (my opinions only)
> --
Mike Stark
Nick Thurn wrote:
>
,snip.
> Totally agree. Often a little manual decision making isn't a bad idea.
> Remember "the crash" when all the programmed trading apps followed
> each other into the ground :)
Of course, humans can do this too :( -- I recall the entire
Thunderbirds
aerobatics team following the lead aircraft into the ground once.
Mike
Andy Brice
Mark McWhinney wrote:
>
> The difference is that werewolves who are created by unseen external
> forces attack their unsuspecting victims without warning. In software
> development, we know what creates the werewolves, when they are going to
> attack, and what they are going to do.
>
> Maybe a better one is "We have met the enemy, and he is us"
>
It true that a lot of software problems are self manufactured and probably down
more to lack of project management than lack of technology. But I think the most
implacable enemy is complexity, and I'm not sure that is ever going to be beaten.
The better we get at handling complexity the more complex systems we seem to
tackle.
Andy Brice
psgo...@aol.com
>Mark McWhinney wrote:
>
>>
>> The difference is that werewolves who are created by unseen external
>> forces attack their unsuspecting victims without warning. In software
>> development, we know what creates the werewolves, when they are going
to
>> attack, and what they are going to do.
>>
>> Maybe a better one is "We have met the enemy, and he is us"
>>
>
>It true that a lot of software problems are self manufactured and
probably down
>more to lack of project management than lack of technology. But I think
the most
beaten.
>The better we get at handling complexity the more complex systems we seem
to
>tackle.
>
>Andy Brice
For more on this, see the thread "Is Software Engineering Engineering?"
We are talking about biting off more than we can chew. Only discipline
can curb this
tendency.
We are also talking about dysfunctional relationships between our
customers and
our development resources. Software development does not live in a
vacuum, it is
inextricably bound to the strengths and shortcomings of our clients. Most
business
management models are based on 19th century ideas about command, control,
and heirarchies of authority. These are the organizations that hire us to
develop
software.
Instead of trying so hard to please them (such as by agreeing to tackle
more
complexity than we know how to manage), we need to engage in mutual
growing up. Simply learning to handle more complexity is a
self-defeating
strategy if we always agree to take on more than we know how to deal with.
Also, software developers tend to develop personal skills, but we are not
very good at
developing skills of cooperation and collaboration. These team skills
reinforce
disciplines. In their (our) hearts, developers want to be heroes. I want
level-headed
professionals spending my money and time, not wannabe heroes.
Psgo...@aol.com
pa...@promarkone.com
---------------------------------------------------------------------------------------------
All perceptions are models. All models are flawed, and
changeable.
Pete and Jane Dietert
psgo...@aol.com wrote:
>Maybe discipline is the silver bullet.
Well said. But even with discipline, I believe some chaos and
innovation is necessary for progress. But I think the mix should be
about 90% discipline and 10% innovation rather than the 90% innovation
and 10% discipline that the industry seems to have now.
Pete D.
Pete and Jane Dietert
Andy Brice <abr...@quantisci.co.uk> wrote:
>Guy Rixon wrote:
>..
>> The complexity of useful systems is limited by the complexity of the
>> human affairs that they support, and we aren't evolving our society fast
>> enough to raise that complexity limit much....
>Not sure I agree with this point. Systems seem to be getting more and more
>complex at quite a rate, at least keeping pace with our ability to handle
>them. In fact the introduction of computers generally (always?) makes a system
>MORE complex.
>Andy Brice
I agree with Andy with regards to complexity. The universe is so
exceedingly complex that I see no limit to the level of complexity
that we may wish to model in software in order to solve our various
problems. We choose what problems to solve - generally just slightly
beyond the reach of our ability to solve them. That's human nature.
Appropriate abstraction of the inherent complexity of the problem is
our only real weapon to attack it.
If one is expecting problem complexity to somehow limit itself, I can
only say that, in my opinion, history does not seem to support this
view. If one wants to limiting problem complexity to manageable levels
the only real solution is basic human discipline (see Andy Brice's
comments in this thread) - Requirements definition discipline, Design
Discipline, Coding Discipline and Testing Discipline. The search for
discipline seems to me to undergird the whole drive to make Software
Engineering a reality rather than just a dream.
Innovation and (relatively) undisciplined theorization and
experimentation certainly has its place, such as in research, and may
provide some solid breakthroughs, but as any researcher knows, this
path is also filled with much stress and frustration at the many
failed experiments.
If we insist on being researchers on every new project and every new
module developed then we must accept the chaos that accompanies that
level of experimentation.
Pete D.
Nick Thurn
Pete and Jane Dietert (die...@istar.ca) wrote:
> The universe is so
> exceedingly complex that I see no limit to the level of complexity
> that we may wish to model in software in order to solve our various
> problems. We choose what problems to solve - generally just slightly
> beyond the reach of our ability to solve them. That's human nature.
> Appropriate abstraction of the inherent complexity of the problem is
> our only real weapon to attack it.
>
model is actually *more* complex than necessary. This is a major cause
of unusability, basically give an incompetent *any* design task and
you will receive a complex solution. Strangely the management of
complexity is often *not* seen as a goal or purpose of abstraction.
IMO the bulk of IT problems are caused by the *accidental* complexity of
dealing with unnecessary complexity, eg integrating and reconcilling
stovepipe systems.
> If we insist on being researchers on every new project and every new
> module developed then we must accept the chaos that accompanies that
> level of experimentation.
>
You mean the status quo? ;-)
cheers
Nick (my opinions only)
>
> Pete D.
>
Andy Brice
> Totally agree. One problem is that complexity may be introduced so the
> model is actually *more* complex than necessary. This is a major cause
> of unusability, basically give an incompetent *any* design task and
> you will receive a complex solution. Strangely the management of
To paraphrase an old quote:
There is no complex problem which, if looked at in the right way, cannot be made still
more complex
Andy Brice
Nick Thurn
> more complex
>
Hey, I've seen it done to simple problems too. ;-) How about an AVL-tree to manage three
items, I kid you not!
cheers
Nick (my opinions only)
> Andy Brice