有些人認為做乙個大型軟體專案跟建一座大橋一樣。你可以根據以往的專案，使用那些歷史資料來評估所需要的時間和資源。這種觀點數十年前就已經被證實為偽觀點；這種模擬出的結論在上世紀九十年代，我在卡內基·梅隆攻讀軟體工程學位時，是我一直嚮往的結果。
現實生活中，大多數值得一做的工程都不會是之前的專案的重複。不要以為當需要一座橋時，你可以「gem install bridge」或擴充套件bridge4j。乙個新的軟體專案更像是這樣：
你是乙個發明家。你已經發明了一種太陽能微波爐，一種以死蟲子為能量的發動機，一種能殺死蚊子的雷射**。那好，有人找到你對你說：
「嗨，發明家，我需要一種無人機，它能夠抓取老鼠(不能是別的動物)，定位我的前女友，把老鼠投擲到她頭上。給出乙個資金預算和工期估計吧。」
很顯然，你會不知道如何入手。你需要理解需求。這種東西以前從來沒有製造過，但這完全不是什麼新技術。無人機已經有了，定技術也有。可是如何能準確的找到老鼠呢？有多少東西是真的需要你去發明的？你可以買乙個diy 無人機，稍加改動是否可以滿足需求？你的客戶是否能夠偷偷的把乙個跟蹤裝置放到他前女友的手袋裡？
做軟體不是一種重複性動作，而是一種發明性動作。在twitter上瘋傳的quora上的這個奇思妙想的貼子實際上跑題了。拿從舊金山走到洛杉磯的步行者做模擬是不合適的。徒步旅行這項活動已經被人類實踐了幾千年了，所有你需要的知識只要在谷歌上搜尋一下都能找到。乙個苦行僧只要走過一次就能了解所有的行程。當你問他從紐約步行到芝加哥的路程，他很可能相當準確的說出來。經過數次的城際間的旅行後，他有足夠的知識來進行相當準確的估算。但如果我讓你告訴我從洛杉磯駕車到舊金山要多少時間，依賴於交通堵塞的狀況，你的估算很可能會相差數小時。
而另一方面，如果乙個有經驗的軟體工程師被要求去開發乙個能自主駕駛從舊金山到洛杉磯的汽車的控制系統時，他面對的上一種完全不同的情況。真正的軟體開發實際是指那些你以前從未做過的東西。這就是為什麼所有的這些拿日常真實生活裡的東西來做的模擬都不靠譜的原因。
為什麼程式設計師預估的時間都不靠譜
乙個我曾經共事過的很有經驗的專案經理曾宣稱說，他會拿程式設計師估計出的時間乘以 值，然後再提高乙個數量級，這樣得出的才是正確的開發所需要的時間。1天時間經過變換後是3.14周。他經過慘痛的教訓才認識到程式設計師預估的時間都是不靠譜的。為了能更精確的對程式設計師估計的時間進行換算，我建立了乙個時間換算...
為什麼軟體開發大都不招女生
我也招人，說說我自己的觀點，幾個因素 國情決定 女性基本上不會以事業為第一 挨踢私企是經常需要隨意性加班的，由於家庭 容貌等因素，讓女性經常性加班顯得不人道 運氣不好趕上系統卡時間點上線或公升級，可能要連續3 24小時不准休息。實施性挨踢企業還經常需要出差，出差就是按月計算，這也是類似問題 家庭性因...
為什麼軟體開發周期總是預估的2 3倍
聽過行百里者半九十吧。這句話在程式設計師的工作中同樣適用，到底是為何呢?matija用乙個精巧的比喻揭示了個中道理。其實這就好比在高峰期從郊外開車回市中心。前 80 的路程很順，高速嘛，可能兩小時就走完了，但是到了城裡，就走不動了，紅綠燈，行人路，各種環線和菜鳥司機，可能兩個小時還不夠用的。程式設計...