Googlemaster on learning from disaster vs success

People don't usually analyze the reasons for success, but they do analyze the reasons for failure. The company I work for has a thing we do called "root cause analysis" and "the five whys" where we dig and dig and dig to try to find the real reason for failure. We don't usually do this for successes. Maybe we should.

- The customer reported a primary key violation on table FOO.
- Why is the customer getting a PK violation on FOO? Because the software is trying to insert two records for the same thing.
- Why is the software trying to insert duplicate records? Because two threads are trying to do the same work.
- Why are two threads trying to do the same work? Because there's a bug that wasn't caught.
- Why wasn't the bug caught before release? Because we didn't test the multi-thread scenario.
- Why didn't we test the multi-thread scenario? We were going to test it, but we ran out of time. (Or, you could branch off in a different direction here and go with "Because we didn't know the software needed to support multiple threads of execution.")
- Why did we run out of time? Because "just a small feature request" was added to the schedule after we did the planning and estimation.
- And so on...