On Apr 25, 9:48am, Patrick Horgan wrote:
***mucho deletia****
> I disagree that Dr. Cohen's arguments are just theoretical, it's fairly
> well accepted in software engineering that stress testing is important,
> and further I've seen many case of my software failing in fairly surprising
> ways under stress testing. Some of these failures had security implications.
I will not denigrate stress testing. It has its place. But is not
a solution for poor design or crappy code.
I think (and this is my own take on the thing, and solely my own opinion) is
that, a la Martin and other software design professionals, testing is not
the answer to help fix incomplete or poorly designed software. If it
is designed with a high degree of bogosity or using poorly conceived constructs
or suppositions, or is built around a fallacious understanding of the problem
to be solved, it is a bogus piece of code. No more, no less. And all the
effort that will go into fixing the bugs and test hiccoughs would probably
have been more usefully spent in the DESIGN and process analysis phase
of the project. The old 80/20 rule: you can get 80% of the results with
20% of the effort; the other 20% takes 80% of the original effort.
As someone that has suffered through the design, code, and production, and
that has seen their share of bogus programs that TEST well, I think it is
necessary, nay, imperative, that the program, process, subroutine, or whatever
you are trying to do be designed as robustly and cleanly as possible before
your ever get to the testing phase. Only then can you validate that the
tests you propose to run are real tests or just pointers as to where the
software has to be fixed because you didn't do what you had to in the first
instance.
It seems to be the fashion among the johnny-come-latelies that you end up with
a monolithic piece of security code that does everything except retina scans,
only uses up 64M of process space, and has enuf patches applied to it to get
it past the stress tests that it looks like a 30-year-old lameframe cobol
application.
People: design it cleanly and simply in the first place from provably correct
constructs and it will work correctly in testing, production, and reality.
For references on writing good code, if you need them, I suggest:
System Design From Provably Correct Constructs, James Martin, Prentice Hall,
Englewood Cliffs NJ, 1985, ISBN 0-13-881483-X
Handbook of Software Engineering, C.R. Vick et al., Van Nostrand Reinhold, New
York, ISBN 0-442-26251-5
--
Bryan D. Boyle |The Moving Finger writes,and having writ, moves on.
#include <disclaimer> |Nor all your Piety nor Wit can call it back to cancel
EMAIL: bdboyle @
erenj .
com |Half a line, or all your tears wash out a Word of it.
--------------http://www.access.digex.net/~bdboyle/index.html---------------
References:
|
|
