The primary problem with lists like this is that they don't compare to successes. For example: * I've been on projects where we're rewritten applications from

The primary problem with lists like this is that they don't compare to successes. For example: * I've been on projects where we're rewritten applications from the ground up that were totally successful and we were better able to build in the future because we had a clean setup. * I've seen government IT shops hire contractors to do a large project and ended up with something better than the internal devs would have done. Both of these are situations where the opposite case (time-consuming and expensive failure) gets a lot of attention. (and, in my experience, failure is more common). Show me one of those failures and my instinct is to say "Of COURSE that was a failure! It was obviously going to fail!". But, in reality, not always. Rather than building unhelpful conventional wisdom, we should be trying to understand the distinctions between the failures and the successes.