Jim,

Well, I as a 'tradeoff-ist' <g> would of course acknowledge variations and broad categories. That's the whole point. Scary as it is there actually are people who try and apply absolutes to sitiations where they are not warranted. In Sowell's book (again recommended) he uses the whole Freon debate as an example. I'll leave it up to you to read his narrative for a detailed explanation. I believe in absolutes and I think that there are a few (very few) places where they apply but I don't think that perfection in software is one of them.

These two categories are, as I mentioned in my message the notion of diminishing returns - which I think is a truism.

I'd recommend you go to your local library, check the book out and read it for a better understanding of where I'm coming from. I'd bet you'll like the book.




>Doug,
>
>While I know that you are fond of finding categories in which to put people (and do not hesitate to do the same for yourself, of course), I hope that you are over-simplifying these particular definitions.
>
>I mean, there is more to 100% than meets the eye, typically in the form of "tradeoffs". For instance, the moon program (and essentially all of the space program) was done by "the lowest bidders" (or near lowest I bet, in some cases) yet only a 100% performance spec was acceptable for any slight piece. Even then there were several parts that were redundantly incorporated by design.
>
>Now I've gotta believe that even a "solutionist" would have agreed at the time that it was (finally) safe enough and as good as it could get, even though he knew full well that tradeoffs had been made.
>
>As for 100% clean software, I'm still betting that it will one day be available. It may come with strings attached, but it will come.
>Those strings may be things like using only certified compatible features/hardware and only specific updates. And it will no doubt be higher priced, at least at the start.
>
>With power growing daily (MIPS-wise) and AI developments underway and all of the mathematicians/engineers/thinkers alive today, its just gotta happen.
>
>
>JimN
>
>>Mike, et al,
>>
>>I don't know if you've heard of the book, "The Vision of the Annointed" by Thomas Sowell but I would highly recommend it. Essentially Dr. Sowell discusses the differences between those who think in terms of 'solutions' as opposed to those who think in terms of 'tradeoffs'. By 'solutions' he means those who think that their 'solution' is absolute - oall too often at the expense of the notion of unintended consequences. Those who think in terms of 'tradeoffs' understand that there will always be consequences - not always favorable.
>>
>>(My take)
>>
>>'Solution-ists' think that software can be without flaws.
>>'Tradeoff-ists' understand that there really is a law of diminishing returns.
>>
>>I read your message and some of the responses you've dealt with as essentially a conflict between these two types of thought processes. I am in the 'Tradeoff-ists' camp and am of the opinion that flawless software is a hugely laudable goal but always out in front of where I currently am. <g>
>>
>>Never stop trying to make the software perfect and never get discouraged when it isn't.
>>
>>
>>
>>>> I see no reason for the software industry to continue with an attitude of “ship it” with known bugs.
>>>
>>>Even when the bugs will never show up in a production environment? There are known bugs in VFP that I can guarantee you'll never find. I can crash VFP7 in three lines of code, but I'll bet you never will be able to. But I can also crash my microwave and my cell phone (still working on crashing my DVD player). I'm a tester, it is my profession. I'll find stuff that no other user is likely to find.
>>>
>>>So do we spend resources to fix something that only a pathological tester can reproduce? No, the risk is too great. For every bug you fix, there's a 60% chance you'll introduce new bugs. Open 100 projects in the VFP IDE, close VFP and fire it up again. Oops, all 100 projects didn't open again. Do you fix that at the risk of introducing new, perhaps more evil bugs? I think not. Nobody in their right mind is going to open 100 projects at once. No customer has ever reported it, and I'm the first tester to find it, and then only by digging through the source code. So why risk introducing bugs that users will find?
>>>
>>>Any test team, whether Microsoft or not, will allow a product to go out the door with known bugs because it's a trade-off between the risk of fixing the bugs vs. the odds that a user will run into it. If a product team fixed every bug that that a competent test team found, any reasonable complex piece of software would never ship. We wouldn't have microwaves or cell phones, either. :-)