Secure Coding mailing list archives
Re: Variable comparisons
From: Danny Smith <Danny.Smith () Sun COM>
Date: Wed, 03 Dec 2003 17:43:27 +0000
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.
Current thread:
- Variable comparisons David A. Wheeler (Dec 03)
- <Possible follow-ups>
- Re: Variable comparisons der Mouse (Dec 03)
- Re: Variable comparisons Dave Aronson (Dec 03)
- Re: Variable comparisons Martin Stricker (Dec 03)
- Re: Variable comparisons Danny Smith (Dec 03)
- Re: Variable comparisons Bob Toxen (Dec 03)
- Re: Variable comparisons Wietse Venema (Dec 05)
- Re: Variable comparisons Florian Weimer (Dec 06)
- Re: Variable comparisons Peter G. Neumann (Dec 03)
- Re: Variable comparisons Peter G. Neumann (Dec 07)