Avoiding trouble

Following post could be seen absolutely obvious mechanism to avoid unnecessary trouble in development process. But it was something new for me when several years ago I've firstly read it from the long term oracle-l list ex member Rachel Carmichael (unfortunately I've lost this e-mail) and now I've seen it is something new for many developers. In one sentence it is:
Inform your boss (customer, colleague or other responsible person) about possible trouble in a written and provable way.
OK now let's explain a bit more. There are three steps in this process:
1) Understand possibility for eventual trouble;
2) Fight for your right decision;
3) If you lost the battle inform responsible person about it explaining why you think there is possibility for trouble.
Let's see what each of these steps mean.

Understand possibility for eventual trouble

Here is the trickiest part. The first tricky thing is to understand that there might be possible trouble. Of course that comes with experience ;) Probably the first time you'll miss the eventual trouble but next time you'll be already smarter. The second tricky thing is to avoid never ending wretch syndrome. And here of course the main factor is your common sense - decide when to warn responsible person and when to not use false warnings.

Fight for your right decision

Almost always there is a possibility to fight for your decision. Of course here is also one tricky thing - you have to explain and motivate your decision. You can enforce your decision with test cases, examples, resources from books, Internet etc. You can find supporters among your colleagues and sometimes even usual opponents. Even if you'll loose at least you'll have clear conscience :)

Inform responsible person about it

This is the easy part. If you have decided that you should warn anybody then most of the time there is no need to seek for a notary. Usually a simple e-mail saved in your sent mails will be enough. You can of course consider possibility to add some more recipients to TO: or CC: fields. If it is a meeting protocol with customer a footnote with warning can be a solution. Of course if the possible consequences are quite serious you have to ensure that your insurance is at least as serious. One thing of course remains - the motivation has to be kept. Also in your written email, meeting protocol or whatever else.

The result

With above mentioned mechanism you've got two points:
1) Once again informed about your decision.
It might be possible that your boss simply missed your viewpoint. Probably he thought you are not serious enough. Probably he misunderstood you. Written text with appropriate explanation and motivation decrease such probability to the minimum.
2) Cover your a$$ (sorry for that expression but I couldn't resist :) in case of failure.
You will be able to point to your written message and say - I already warned you. Without it there are always place for different interpretations. Even the most ordinary thing - your boss probably simply fairly and honestly forgot about your warnings. With such cover even if you need to clean up the mess you won't pay for it. Your boss, your customer or whatever else responsible party being warned will pay for it.

Have I used that?

Yes, I have. I was lucky enough to have knowing and smart bosses till now so I haven't necessity to use such scenario (3rd step) inside my company. Either I could convince my bosses or the problem was out of my responsibility. But in communication with customers I've used this technique quite much along with catching their bad requirements. Sometimes that convinced them at last change their minds, sometimes not, but at least I and my company had very strong argument in case of failure.