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.
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.