你有沒有試過復原魔方，但始終搞不定？在一次乘坐長途客車的途中，我試了幾次，但無一成功，著實深受打擊。後來我聽說有些孩子可以在很短時間內搞定！這怎麼可能！
（補充：魔方世界紀錄 4.904 秒，Youtube 視訊：https://www.youtube.com/watch?v=vh0W8E4cNkQ 。不方便的朋友，請看伯樂線上轉制的 GIF 動圖：http://ww1.sinaimg.cn/mw690/7cc829d3gw1f6u9gvax15g208w04znpi.gif ）
無法預料的複雜性
作為一個程式設計師，當你開始一個新專案時，由於種種原因，通常並不會特別清楚如何實現它。但作為一個專家，而且以前已經做過幾個類似的任務，所以要麼你自己想辦法搞明白怎麼做，要麼找找看誰知道再諮詢一下，或 Google 一下。
通常情況下，直到你掉進去，你才知道你已入坑！
（Via：@程式設計師的那些事）
比如這些情況：
- 你需要用新框架、新庫重新實現某個功能。
- 你打算用到的一個庫跟你以前用的不大一樣。
- 你一直熟悉的API無法實現部分預期功能。
- 你用到的框架與單元測試和整合測試不一樣。
- 你原以為新框架中的某個模型是單例模式，然而它並不是。
預料外的估時複雜性
“你幫我估計一下這個任務的工時吧？”，你的老闆問你。還記得你沒搞定的魔方麼？如果讓你再來一次，你覺得你多久能搞定？
“啥？兩天？”，“但是我們上一個工程師只要幾個小時就搞定了！你絕對不能花費這麼長時間。”
確實有種演算法你可以學習一下，稍作練習，就可以幫你很快解決魔方的問題。但是你現在還不知道這演算法，而且也沒有任何跡象表明你一定會找到正確的演算法，即便能找到，也未必僅僅花你兩天時間。
累加複雜度
任務越多，你就越容易陷入這種窘境，也就是說，如果你不盡量延長你的預估時間，你幾乎無法保證按時交付。
我們不妨簡單算一下，就能看的更明白。就算你是個經驗豐富的程式設計師，僅有 5% 的可能會遇到預料外的複雜情況。如果你接手一個新專案，並把它拆分為 10 個小任務…
1 – (1 – 0.05) ^ 10 = 0.40
即：你有 40% 的可能碰到一個複雜任務，你對該專案的所有預估就都吹了。
在《為什麼專案基本都在延期？》這篇文章中，有更多數學證明和超過 70,000 工時的專案指標討論這個論題，看看有沒有你感興趣的？
創造性和重複性任務
Einstein trying to estimate a project
問題已經深入到需要很多思考的任務，以及一些你已經具備經驗的常規任務之間的區別了。
在《論軟體行業的規模不經濟性》一文中，從生產率角度，就這種差異性進行了非常有意思的討論。對於創造性任務，工作量越大，單個任務耗時越多；而重複性任務正好相反，它們通常可以在一定程度上自動化。
這麼看來，貌似根本沒有辦法估計創造性任務，連可供參考的經驗都沒有。猜猜看，愛因斯坦需要多久才能完成物理大統一理論的發現？