Message-ID: <200411171858.iAHIwH403200@pop-2.dnv.wideopenwest.com>
From: mvp at joeware.net (joe)
Subject: IE is just as safe as FireFox

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: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Eric Paynter
Sent: Tuesday, November 16, 2004 4:19 PM
To: full-disclosure@...ts.netsys.com
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

Powered by blists - more mailing lists