I have a habit, some would call it a bad habit, of fixing bugs whenever I see them, usually without ever filing a case in the bug tracking system or telling anyone that I found the bug at all. Usually this happens when I’m reading through code I’m not ostensibly working on. When I see bugs, I fix them. Someone with fewer battle scars than I have may think that’s a great habit and that there’s no need to apologize. Here’s why I should always file a case, even if I fix the bug right then:
- Some other developer may unknowingly (or worse, knowingly) depend on behavior that results from the bug. In other words, fixing the bug may break something else.
- Your customer may expect or worse depend on the behavior caused by the bug. Bugs that are found in code review are usually issues with business logic. If the bug causes the app to blow up, you rarely need a code review to find it. Customers deal with the interface they’re given, so business logic or formatting issues that look like bugs internally can become part of the de facto contract you have with them. Making changes without telling anyone can create unpleasant surprises.
- In fixing the bug, you may break something else. Any time you edit code, you may introduce a defect. Heck, some developers are as likely to introduce a defect as not. If you change code without telling anyone, you may fix one bug but introduce one that’s even worse, or you may not really fix the bug.
- Your testers need to know what to test. Your changes may not get tested if you don’t tell anyone what was broken or why and how you fixed it.
Update: Be sure to check out frequent commenter Stan Taylor’s follow up post on this topic.