of something you've documented properly. I've challenged you on many occasions to show, just as one example, that the "reset problem" that you've apparently encountered more than once, was, in fact, a reset problem. All you've ever said is that your customer stopped complaining after you did whatever you did.

I'm still curious how, never having determined that you had a problem related in any way to RESET, you proved that you had solved the problem, since you had no way of knowing that the malfunction was "cured."

Of course, I do understand that the true goal is to get the customer to stop complaining yet continue buying your product. I imagine that you either met that constraint or moved on to another employer.

You professional coders don't like rigorous methodology. That's why you don't like documentation. Documenting your design means specifying what you have to do before you do it, rather than commenting on what you did after the fact. Lots of projects, large and small are documented only in the "as-built" documents. That allows the designers to hide their sloppy work, or lack of it, so they can't be sued for incompetence.

RE