The primary problem with lists like this is that they don&#x27;t compare to successes.<p>For example:<p>* I&#x27;ve been on projects where we&#x27;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.<p>* I&#x27;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.<p>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 &quot;Of COURSE that was a failure!  It was obviously going to fail!&quot;.  But, in reality, not always.<p>Rather than building unhelpful conventional wisdom, we should be trying to understand the distinctions between the failures and the successes.