Suppose that you have a 'sender stores message' email system, and thatyou protect yourself against the sender rewriting the message after it'sinitially sent by sending and verifying a secure hash of the messagebefore you show the message to the user. To follow up a recent entry , here are the social and technical issuesthat I can see with this hash protection scheme.

First and largest, you have a social issue; users are going to reactbadly to 'this message is (minorly) corrupt so I

I am not really tuned in to test driven development yet, although I'vewritten some programs that way (and found them quite valuable). As aresult, I have some weaknesses, some TDD things that I just haven'tacclimatized to yet.One of them is mock objects, specifically mock versions of complexobjects; I don't like them and thus I don't use them. In trying tounderstand my dislike of them, I think that they seem too complexand fragile for at

There is a certain school of thought in system documentation thatbelieves, to stereotype things, that there is no such thing as being tooexplicit or having too many examples. Much of Sun's Solaris documentationmakes a great example for this school.

Unfortunately, these people are wrong. There is such a thing as toomuch documentation, because having too much has a number of problems:

• your documentation becomes less and less readable, as the importantthings are buried under a flood of examples, cross references,and low