This question already has an answer here:
A little story as motivation for my question: I'm an experienced coder (15+ years), I do non-basic stuff (multi-threaded, distributed, "scale-out" style architectures) in various languages (Java, C#, C++, Clojure, JS, etc.).
Now I've always been prone to "slips of the pen", and that includes my programming. Most of the time this has not been an issue, because the program will not work as expected and you'll generally notice before you ship it, even before testing gets done by QA, or there are code reviews and normally you'll notice problems reviewing the code yourself in anticipation of the code review.
But sometimes, you are pressured into quickly making potentially major changes that will be applied without being checked. In other words, you have to instantaneously produce "perfect" code. So here's what happened:
I had to port an app from Java to .net, and use that app as part of a distributed benchmark consisting of a bunch of other apps. I had written the Java app and properly tested and reviewed it. Porting went pretty smoothly, as only minor threading issues and some library issues had to be addressed. So I ran the benchmarks, which in itself took a full day. I created the report, presented it, and afterwards figured out that my serialization code (which I could not port from Java, but had to do from scratch in .net, as the Java version did serialization automatically) missed one important line: The serialization of the payload. Though technically insignificant, as all the meta data for routing etc. did get properly serialized, it substantially invalidated the test results.
Well, I wrote that "I" figured that out. The truth is way more embarrassing: I delivered the source code to our client, and the client discovered the mistake.
In other words, this single missing line was
- extremely embarrassing for me personally
- embarrassing for my company
- expensive, as the benchmark will have to be done again
Now I'd like to hear suggestions how other people prevent problems like this from occurring, especially in cases where the "obvious" things that everyone should always do - if they've got time for it - like code reviews, are not possible.