Fix bugs, or wait for the customer to find them

Do other people fix bugs when they see them, or do they wait until there's crashes/data loss/people die before fixing it?

Example 1

 Customer customer = null;
 ...
 customer.Save();

The code is clearly wrong, and there's no way around it – it's calling a method on a null reference. It happens to not crash because Save happens to not access any instance data; so it's just like calling a static function. But any small change anywhere can suddenly cause broken code that doesn't crash: to start crashing.

But, it's also not inconceivable that correcting the code:

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

might introduce a crash; one not discovered through unit tests with complete coverage, and manual user testing.

Example 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

People knowing physics will recognize that it's supposed to be R² in the denominator.

The code is wrong, it's absolutely wrong. And overestimating the speed will cause the retro-rockets to fire too soon, killing all the occupants of the spacecraft.

But it's also possible perhaps having it over-estimate the speed is masking another issue: the air-bags can't deploy while the shuttle is moving too fast. If we suddenly fix the code:

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

Now the speed is accurate, and suddenly airbags are deploying when they shouldn't.

Example 3

Here's an example that i had recently, checking if a string contains invalid characters:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

What if it turns out there's a bug in the Do something branch? Fixing the obviously incorrect code:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Fixes the code, but introduces a bug.

The way I see it there are two possibilities:

• fix the code, and get blamed for breaking it
• wait for the code to crash, and get blamed for having a bug

What do you politically do?

Example 4 – Today's real world bug

I am constructing an object, but calling the wrong constructor:

Customer customer = new Customer();

Turns out that the "parameterless" constructor is actually an parameterized constructor from further back in the inheritance chain:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

Calling it is a mistake, since it bypasses all the subsequent constructors.

I could change the object's lineage to not expose such a dangerous constructor, but now I have to change the code to:

Customer customer = new Customer(depends);

But I can't guarantee that this change won't break anything. Like my Example 1 above, perhaps someone, somewhere, somehow, under some esoteric conditions, depends on the constructed Customer to be invalid and full of junk.

Perhaps the Customer object, now that it is properly constructed will allow some code to run that previously never did, and now I can get a crash.

I can't bet your wife's life on it.

And I can test it from here to Tuesday, I can't swear on your daughter's life that I didn't introduce a regression.

Do I:

• Fix the code and get blamed for breaking it? or
• Leave the bug, and get blamed when the customer finds it?