>>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.

I've had this happen a few times in non-Communist companies :-) Small companies in niche markets/businesses often don't have their processes fully thought out. When they go to automate/"computerize" them, sometimes the simple process of normalizing a prototype database can yield valuable insights. Or, handling "exceptions" forces generalizations that increase the flexibility of their whole business process. I've seen the "lights go on", in this fashion, at several clients over the years. I find it amongst the most satisfying and rewarding work in the consulting/development field.