Joel Rees wrote:
[...]In fairness, computers are now so complex that it is almost inevitable that some unforeseen circumstances will arise. Not that this has any relevance to the problem I've just had, but I don't feel that it is possible, today, for any systems designers to be absolutely sure that nothing odd could happen.Umm, not so. I recall my "software engineers" complaining that their software/firmware could not anticipate every possible circumstance. I would point out to them that "Your code is going to do *something* in every circumstance. What it does can either be something you *chose* for it to do, a *considered* decision, or it can be something you simply *let* it do, *without* any consideration. Which do you prefer to have to support?" These days, all the "complex interactions" are pretty much due to intelligent devices with uCs running firmware. If it does something weird, then that's just some firmware writer being in a certain sense "lazy".I would say that depends on the definition of lazy. It's kind of like
I put it in quotes. A *really* lazy programmer (like me) tries to make his code as absolutely bullet proof as possible before going to test. The more time spent in getting good requirements, the better. IIRC, the costs for recovery go up about 3x going from requirements to design to code at each step, and then about 9x to rlease.
professors who stand up in the intro to compilers class and say, "A good compiler could completely do away with the need for a program stack." In the ideal, yes, but ideal processors have infinite memory and run at infinite speed. Sure, there are plenty of lazy engineers, programmers, and techs, and plenty of impatient project managers, and plenty of sales personnel only too happy to promise impossible delivery dates, etc., but there are also problems that are difficult to solve, and testing can definitely be part of that class of problems, particularly when the machine being built has to deal with humans fumbling around.
It is impossible to "test in" quality. It begins with requirements. The purpose of test should be to verify proper operation, not to find defects. It is much more efficient to find defects by means of inspection/review. And that starts, as I said, with requirements.
I don't think anyone has yet found a solution to the general class of NP-complete problems.
Please give an example of an NP-complete problem which must be
solved by firmware in the electronics of an ATA disc drive.
Not many traveling salesmen in my discs...
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
