I would rather not get too deep into this. But I think you are mixing the ideas of good code with good documentation or possibly with good hard design specs.
In any project there are going to be things that aren't specifically specified in the design that some other module could possibly take advantage of. These are generally considered implementation details. For a basic example, say you have a routine that takes a search filter and returns information based on that filter. Let's say when the spec was written, no thought of the ordering of the data to be returned was defined, it was simply a matter of return the correct data. Actually specifying the order possibly wasn't important or overlooked. Some very high quality code was written to the spec and the specific implementation detail ended up having it so the data got returned in a way that was sorted by some field used in the query or by some arbitrary value specific to the indexing. Someone completely unrelated to the module, say someone who is using that module as an API or as a server app notices that it always comes back sorted and implements some stateless retrieval mechanism around it (I understand, this is their F-U and they wrote bad code here because there are critical untested assumptions). This works for years and years. Then some work is done on the original code and that implementation detail changes and sort is now done in a different way or not at all. Downstream modules dependent on that until then well understood implementation detail implode. The original code was still high quality. Someone just used it in a way that wasn't intended. It is these unintended uses of implementation details that can really bite you and why YOU ALWAYS legacy test code that may be used by something else. I don't think any spec will ever define out 100% what needs to go in and what needs to come out and all of the possible implementation details that could result. I think we can get close and assert the crap out of the input and output based on what we expect and break out when it deviates. But this is an expensive form of coding and I think impacts flexibility a little. Anyway, on the flip side you could have horrible spaghetti code that conforms very well to a published spec as well. I would tend to agree that normally that would be harder to work on (except for maybe the person who originall wrote it) but want to put emphasis on the importance truly being in the spec and data assertions. I completely agree that IE is too intertwined and it gives the appearance that the OS needs it. It does need to be stripped back out or the piece that allegedly has to be there for OS functionality needs to be stripped down to very bare very basic pieces that disallows and extension or code execution. joe -- Pro-Choice Let me choose if I even want a browser loaded thanks! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Paynter Sent: Tuesday, November 16, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] IE is just as safe as FireFox But high quality code that has a sound and well documented architecture can be more easily updated without messing up dependencies, whereas low quality code can be a nightmare to find let alone correct even the most trivial bug. There are always exceptions, but *in general*, it is easier (less effort, faster turnaround) to maintain high quality code. -Eric _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html