Jim-

>>You do realize that functioning "perfectly properly for their users throughout their useful life" is _not_ the same thing as being "bug-free?" It only means "bug not found." Or "bug not noticed."
>>
>Yes, and I can accept that NEVER found/noticed (by anyone, anywhere, at any time) is a defect but in my opinion would be immaterial to the argument because (again, my opinion) it would never participate in any counts of defects anywhere.

So, a bug is only a bug if someone knows it's there? Kinda of a Shrodinger's cat thing? I'm afraid I think a bug is a bug even if I haven't found it yet. But, call me picky. IAC, you stretch the point to the degree of absurdity, but it actually holds up. Which is a good sign. You precisely point out the impossibility of _knowing_ we have defect free software. So, why strive for a goal we can't even measure? Why not strive, instead, and spend our resources on, goals we _can_ measure?

> For instance, Mike S. described some defect he found relating to something like 100 projects being open simultaneously. Allowing that that is NEVER going to happen...

Never? It did.

> no one is ever going to see it, so it is never going to appear in a bug list, so it doesn't matter.

To you.

You asserted that code should be, could be "bug-free" and then went on to equivocate by saying that it was good enough if the program worked for the user through it's life. I think that what you are looking for is code that is more robust and able to keep you happy as a user. You don't, actually, care if code is, really, bug free. That's good, I think. Shows you have are a practical man. :)

>>Even if it is possible that code is bug-free, no code of any useful complexity can be proven to be so. And, of course you increase the cost of development past the point of benefit the closer you try to reach 100%.
>
>While that is undoubtedly true today,

No it is true forever by the virtue of what constitutes "proof."

> it is my firm belief that not only will this change, but it will have to change. I suspect that you are correct in that, initially, the costs for such software will be higher and available only in specialized businesses/applications (where they can be afforded).

> But technology will meet the challenge and then all software will be defect free as a standard.

There are a number of problems with this.

1) At some point bug or defect is subjective and depends on context and users.

2) Given that it is impossible to test all aspects of a software in all contexts and with all users, it is impossible to prove that code is defect free. If that's the case, then how would you ever know when to stop? Add to this the fact that code runs on equipment in contexts for users not envisioned during implementation, and you have an impossible ideal. Does this matter? I do. One can put 90% of one's budget to protecting one's house against, say, a falling satellite. And miss the dry rot in the foundation.

I am interested in the part of your comment that technology will meet the challenge. Of course, one must have vetted the technology used for testing, fixing, and validating as 100% defect free in the first place in order to have that level of confidence in the target. Even if we leave the job to humans, humans, of course, also have their defects. Is it really "turtles all the way down?"

>A small step in that direction is evident in the "MSDN News" (July/August, 2001) where it says "All versions of Windows 2000 use the same executable code to run Win32-based applications. In fact, the only difference between these binaries from one language to another is in translation of their resources...". The story is talking about international/multilingual support, and it goes on to name the numerous benefits. Obviously the best ones are a single source without (language related) conditional compiles and reduced development time.

I don't think this really substantiates your position that well. What about next year? And, "in the translation of resources" too could introduced defects. Reuse does help us to make our applications more _stable_. If only we limited ourselves to making bug fixes and never adding new functionality, that would be one thing. But we don't. What about next decade? Reuse is not a panacea, because code changes over time because needs change and platforms change. Also, let's consider that every bug fix is new code, and requires the same testing and validation. Whew. I can imagine that VFP releases are going to be even _further_ apart. :)

This is, of course, leaving aside the even more difficult problem of subjectiveness in assigning defect status.

>
>I think that MS realizes that it is going to have to produce defect-free code in the near future. I believe that they are working toward that end.

I, too, feel very warm and fuzzy about how hard MS in general, and our beloved Fox team in particular work to give us solid, responsive code. I'm glad to see you're a supporter. However, I sincerly hope they are pursuing more productive lines than zero-defect code.