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

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.

Solution

Get them to write unit tests to cover each case.