Never change something that works

In my job I often face this situation.

Something goes wrong in a web application, so an issue is reported, an I’m given the task to fix it.
While debugging, I discover many other bugs and fix them as well.

Sometimes a fix of mine breaks the application elsewhere, far away from where the original issue was detected.
This is quite a common problem for me, and I think for developers at large too. Nonetheless, when it happens my boss reminds me that say: Never change something that works. I don’t share this point of view.

  1. A bug is to an application, what a mine is to a field.
  2. A buggy application is like a mined field.
  3. Running a buggy application is like walking on a mined field.
  4. A test-passed functionality is like a marked path.

You can safely walk on marked paths. Anyway, as soon as you leave them, you start marking a new path. Not blowing up is only a matter of luck. And, blowing or not blowing up on any new path doesn’t tell anything about the rest of the field. That’s why application testing is a requirement, but exhaustiveness is just a Chimera.

Leave a Reply

Your email address will not be published. Required fields are marked *