I wonder if the developer who caused the bug got fired. As a developer, this is one of the few nightmares I get at night :) (making a small change and bringing every thing down)
With that understood, systems and processes should be designed to catch the errors early and hopefully long before they reach live.
This is the insurance policy that TDD gives you, this is why you make all of those unit tests, functional tests, etc.
I wouldn't sack a developer who did this, I'd look at my processes and ask why they didn't catch this. After all, if 1 developer can push low quality code to production, then they all can.
The problem isn't with the developer... as with everything in the cloud, expect failure and design to handle it. Sometimes the failure is human, so design to handle that too.
[...] while Test Driven Development is very popular right now, a survey of all of the studies that have been done on TDD have shown that the better the study done, the weaker the signal as to its benefit.
However I didn't claim it improved quality, just that it's an insurance policy.
What I mean by that, is that you pay up front in time, to help protect against things going wrong in future... such as shipping code to production that allows anyone to login to anyone else's account.
All unit tests are, are externalised asserts about what your code should and shouldn't do.
There should certainly have been one that said, "User A should not be able to login to User B's account.", or at the very least "Login should fail when the password is not right.".
My point remains: You should expect people to make errors from time to time, just like you expect servers to go down from time to time. Whilst you're busy handling what happens when servers fail, you should also be busy thinking about how to deal with human errors too... and that means detecting and catching those errors early so that the impact that they have is minimal.
