Our team was busy. So we farmed out the fix for a defect to a DBA. He did not know the business very well. He only had good PL/SQL coding skills. This DBA coded up a fix and presented it to my team lead. He looked it over, and thought it seemed fine. However my team lead implored me to do a deep review of whether this actually fixed the problem.
Now I was a bit hesitant to take on this work because I was very busy. However I usually defer to the boss. So I started going through the solution. I was shocked to find that the code changes actually broke the general case. To add insult to injury, the changes did not even fix the original problem. I sent an email to the DBA, and called up my team lead.
I was glad this stuff got reviewed before it was shipped out to the customer. We would have had even more emergencies if this buggy code went out. I am not sure what the true lesson was here. Perhaps it is that you must do in depth peer review if the developer confidence level is low. I would hope the other lesson learned is that you need to get deep into the code and the business. Otherwise you won't even be able to tell if what you are doing is correct or not.
A Little Bit of Crypto - I have been trying to figure out to "collision resistant" some of these standard hash functions are. It is a tough concept to get my head around. I figure...