>Wow, great topic, John. One could write (and some have written) entire books on this.
>
>Bugs, or flaws, should always be revealed. Hiding a bug or hoping it'll never be spotted is inviting future problems or loss of business.
>
>IMHO, remedies depend on the nature of the flaw. If it's a syntax or coding error, I think you own up to it and fix it. Immediately. The clients should have some reasonable expectation of workmanship.
>
>OTOH, if the flaw is traced to an invalid understanding of the underlying business logic, it's important first to figure out how the misunderstanding was introduced. A good developer is like a good private detective and can usually smell flaws in business logic before the code has been written. But, sometimes, you're just not on the same page as your client and a misunderstanding makes it's way into the application. The burden in those cases is still on the developer because your job is to translate their business into our processes and not the reverse.

I've seen, and done, the reverse. It's the late-communist era companies, where they simply couldn't enforce any persistent document flow, and the way they were organized was partly chaotic, partly incomplete. So they bought the software from us, hoping that its set of rules will force the staff to get their act together.

This worked, most of the time. On a psychological level, most of the staff still believed that computers are a vis maior, and best not fought against, so this helped enforce some discipline "because we must do it this way - it's them computers". OTOH, in some places we, programmers, knew their busines better than they did. We've been through dozens of businesses and had to learn their business logics; most of the clients' staff worked in two or three. So we were the vehicle to transfer the knowledge, and I often had the pleasure of seeing something we suggested spring into life.