How can I convince my co-programmers not to do paranoid "just to be sure programming"?

Question

I've often found that when a programmer or the one assigning the task doesn't really understand how a solution could work, they kind of randomly add stuff until it works.

Examples:

Repainting a window which for some reason isn't painted as the programmer would like it:

Invalidate(); Revalidate(); ProcessMessages();  Update();     Repaint(); Repaint(); ProcessMessages();  Repaint(); 

Over-cautiousness:

function test1(x: boolean)  begin   select case x     true: // do something     false: // do something else     else       raise Exception.Create("Invalid value.") // just to be sure   end; end;  function test2(x: Integer); var   y: Integer; begin   y = Abs(x);   if y >= 0 then   begin     // do something   end; end; 

Although especially the over-cautious coding practices lead to compiler warnings in most languages, I've actually seen all of the above in production code!

In most cases this kind of coding is defended by the programmer and/or the boss. The reasons always come down to this response:

• Well, does it hurt if we double check? Better be safe than sorry!
• It's defensive programming, didn't they teach that at the university?!

Unfortunately I'm out of good reasons not to do this, although I still believe this is really really bad style, which can have bad repercussions.

Are there hard facts I can present that this style has bad repercussions eventually?

EDIT: Thank you for the good suggestions to get rid of this style. But I'm still interested in reasons I can present to my co-workers to explain and possibly convince them, why this is bad and it is in their best interest not do be paranoid.

Answer 1

Get them to write unit tests to cover each case.

Answer 2

Force 100% branch coverage for unit tests, or build fails. He won't be able to get test1 to throw the exception, or evaluate condition in test2 to false.