Re: Variable comparisons

[Danny Smith <Danny.Smith () Sun COM>]

Even worse than that:

At one software engineering seminar I attended a *long* time ago, indicated 
that bugs occur when the complexity of the problem being solved exceeds the 
ability of the programmer solving it.  They went on to say that if the 
problem was too complex for the writer, then anyone that comes along to 
patch the bug will also continue to find it too complex, and hence will 
likely introduce more bugs into the equation.


The two solutions to this are:

. design simpler systems

. employ the highest calibre coders you can find, and stick them onto bug 
fixing (yeah, right!).



We continue to create increasingly complex systems.  Is it even possible 
anymore for one person to understand all the implications throughout the 
whole system?


danny



--On 12/02/03 17:26:21 -0600 Edward N Schofield wrote:


As a person from an EDP Auditing/programming background, I
wholeheartedly agree with you, Chris. One area that is profoundly
impacted by your observation is development cost. Testing the begeebers
out of a system occurs after all the design work , coding, and (maybe)
documentation has been completed. It is very unlikely that any IS
manager would want to go back to his management and ask for the money to
go back to square 1 because the design he approved didn't take
everything  into account. The normal response is to throw more people
and money at the project to "get the bugs out."  The cost ratios I
learned about 15 years ago were that $1 spent solving problems at the
design phase saves about $10 in trying to fix problems when trying to
implement the system. That's a rough figure, and maybe improved
development tools have brought it down......a little.  Pardon the bad
pun, but I agree putting the effort into designing problems out of the
system makes a lot of cents.
Ed Schofield

Chris Richards wrote:

> > This technique, and others, was shown to me years ago when I read
> > "Writing Solid Code" by Steve MacGuire published by MS Press under ISBN
> > 1-55615-551-4. Unfortunately, I'm not sure if the book referenced is
> > even available anymore other than through used channels.
>
> I have a subscription to Books24x7.Com (actually through SmartCertify,
> because I took the MCSE training series from them), and they have this
> book as part of their online collection, as well as links to Amazon so
> that you can buy it.
>
> I may actually buy this book.  Despite the fact that it is from
> Microsoft.
> : -)
>
> The book points up something that I think bears discussion, and I
> believe leads to the point of this list:  Far too much of software
> development seems to rely on testing to uncover flaws, rather than
> focusing on design to prevent flaws.
>
> I have a hardware background, and spent some time in manufacturing
> before I got into software.  One of the things I learned very quickly
> is that it is far cheaper to design a problem out of a product than it
> is to test a problem out of a product.  It seems to me that a large
> part of the software industry has yet to figure this out; it doesn't
> seem to get taught to the young people coming out of University, and us
> older folks that have had to learn as we go haven't always been exposed
> to the concepts necessary to foster this type of attitude.