A list of fairly accurate examples of why estimates are always wrong.  I agree with almost all of the points except for ‘Technical Debt’ and Refactoring.

Refactoring in real projects is rare (I just completed studying 1000 different unique systems) in my research and have very minimal evidence that this is a consistent practice.  Yet, systems seem to evolve fine.  In fact, redundant blocks of code (i.e. copy&paste blocks) seem to be quite common, yet does not cause any observable pain.  If it was a good practice, and actually made economic sense it will get used.  Developers will appy practices that are sensible and useful — if they are ignoring certain so called wisdom, we should really be questioning the wisdom.

‘Technical debt’ (hacks, workarounds, compromised design) is one of those terms that makes a lot of sense when we take a cursory look at it.  My experience has been that there is a quite a lot of resilience built into any software project (or any human endeavor for that matter).  The issue is not that hacks are bad, it is always the extent to which you do these.  Some amount of technical debt is unavoidable — esp. if you intend to ship a project in a certain timeframe.  Like in real-estate, if you cannot service the debt, then you get foreclosed.