複製:不懂技術的人不要對懂技術的人說這很容易實現

原文複製:http://www.vaikan.com/im-sure-it-will-only-take-you-a-few-days-to-code/

這個網站至關簡單，全部你須要作的就是完成X，Y，Z。你看起來應該是技術很好，因此，我相信，你不須要花費太多時間就能把它搭建起來。」

我時不時的就會收到這樣的Email。寫這些郵件的人幾乎都是跟技術不沾邊的人，或正在研究他們的第一個產品。起初，當聽到人們這樣的話，我老是十分的惱怒。他們在跟誰辯論軟件開發所須要的時間？但後來我意識到，即便我本身對本身的項目預測要花去多少開發時間,我也是束手無策。若是連我本身都作很差，我何須對那些人惱怒呢？

真正讓我鬱悶的不是他們預估的錯誤。問題在於他們居然認爲本身能夠作出正確的估計。做爲開發人員，咱們常常會發現，在軟件開發的問題上，一個外行人會很天然的把複雜的事情估計的很簡單。

這並非爲咱們的憤怒找藉口。但這引發了另一個有趣的問題：爲何咱們天生的預測複雜性的能力在遇到編程問題時會失靈？

爲了回答這個問題，讓咱們來認識一下咱們的大腦如何估計事情的。有些事情對於一些沒有經驗的人也很容易預估正確，但有些事情則否則。

咱們來想一想觀看一我的彈吉他。即便你歷來沒有彈過吉他，在觀看了一場彈奏《瑪麗有隻小羊羔(Mary had a Little Lamb)》的吉他表演後，你也能大概推測出這很簡單，一我的不須要過高的技術就能演奏出來。一樣，當觀看了有人演奏D大調的《卡農(Pachabel’s Canon)》後，你也很容易推測出，這很複雜，須要很長時間的練習才能演奏的出來。

爲何咱們可以很迅速準確的預估這兩首曲子的複雜性呢？這是跟咱們用來判斷一個事情簡單和仍是複雜的方法有關的。咱們的大腦有一些現成的模式來完成這些事情，首先一個就是根據速度。這種狀況下，大腦會辨別每秒鐘演奏的東西。根據每秒鐘演奏了多少東西，咱們很容易有一個直觀的判斷曲子的複雜度。由於用吉他演奏一首歌是一種物理過程，一種感官上的活動，咱們的大腦很容易依此來推測速度，繼而轉換成複雜度。

咱們還有另一個天生的推測依據：體積。想一想把一個賬篷和一棟公寓放在一塊兒對比。即便一我的歷來沒有學過建築學，他也能告訴你一般設計和建造一個賬篷會比設計和建造一棟公寓要簡單。爲何？由於咱們天生的會使用物理體積做爲事物複雜性的一個指標。

固然。上面說的這兩種邏輯分析並非老是100%的有效。但大多數狀況下，人們就是這樣幹，並且很成功。大多數狀況中，咱們在對物理過程評估時，咱們的大腦會對物理事物進行有效的關聯，不須要依賴以前的經驗。

如今讓咱們來談談軟件。當一個不懂技術的人試圖對軟件開發時間進行評估時，有兩個很基本的直觀指標在輔助他們：以體積爲指標的複雜度和以速度爲指標的複雜度。但他們沒有意識到，軟件跟他們想象的不同。軟件本質上不是有形物質。沒有體積和速度。它的極小的組成部分可能會時不時的在電腦屏幕上閃現。正由於如此，當面對開發一個web應用時(或任何類型的軟件)，咱們的基本直觀感受失效了。

這第一點，速度，很顯然根本不可能被外行人拿來對軟件進行評估。因而很天然的，他們傾向於使用體積指標進行評估。要麼是根據描述文檔的頁數，要麼是根據軟件的功能用例數或特徵數。

有時候，這種評估手段確實有效！當面對一個靜態網站，沒有特別的設計要求，外行人很容易用這種方法估計出開發時間。可是，一般狀況下，對於軟件開發，體積並不能真實有效的反映複雜度。

不幸的是，對於軟件的複雜度，惟一有效的推測方法是依據經驗。並且還不是時時都好用。做爲一個程序員，我知道，根據我以前開發過的類似的功能特徵，我能夠估計出如今的這些功能特徵各自要多少開發時間。而後，我把總時間加起來，這就獲得了完成整個項目須要的大體時間。然而，事實狀況中，每一個項目在開發過程當中都遇到2、三個瓶頸。這些瓶頸會肆意的消耗程序員的大量時間，你在遇到它們以前根本不會有所預見。它們會拖住整個項目，導致工期延後數週甚至數月。

這些是沒有經驗的人在評估複雜度時不會理解的。他們不明白在其餘事情上都很靈的方法，爲何放到軟件開發上就不靈了。因此，下一次當你聽到有人說「我想你幾天時間就能把它開發出來」時，不論是誰說的，都不要懊惱。深呼吸一下，告訴他這篇文章的地址，本身該幹什麼還幹什麼。