軟件工程時代結束 軟件開發工程化時代到來
Tom DeMarco是著名的Peopleware: Productive Projects and Teams一書的合著者，然而在這個月，DeMarco向IEEE的計算機協會提出個人意見：軟件工程時代結束了。
大多數計算機軟件開發者必讀書目中都包含Peopleware一書，它于1987年首次出版，1999年再版。
盡管出版多年，Peopleware依然具有重要參考價值，因為它并不注重軟件技術本身，而是關注人的因素。
因此，DeMarco給這本書起了一個帶People的名字。也許并不像Steve Ballmer，Steve Jobs或者Linus Torvalds這些大師們演講時擁有那么多粉絲聽眾，但DeMarco依然是全世界高質量軟件開發從業者們執著追隨的對象。
一個類似的公告出現在今年7月Computing Now雜志（IEEE計算機協會的出版物）的DeMarco視角專欄，標題為《軟件工程：一個過時的概念？》。
這在很多層面上都是很吸引眼球的，除了DeMarco的作者身份以外，標題還蘊含著出人意料的觀點：軟件工程是一個正在消失的概念。
實際上，DeMarco本人就一直引領著軟件工程的現代觀念，在Peopleware之前，他寫了Controlling Software Projects: Management, Measurement and Estimation（《控制軟件開發項目：管理，測算和評價》）一書。
這本1982年銷量冠軍的第一行文字在接下來的27年中被廣泛引用，DeMarco在其中寫道：一個人無法控制他不能測算的東西。為了解決這個問題，軟件工程師們克服重重困難，勇敢地一次次去分析和揭示一切軟件里可能的規律。
可是，隨著時間的推移，DeMarco現在顯露出對其原先所持觀點的不安。
那句引文中（書名也是）暗示了控制是一個重要的方面，他說，也許對任何軟件項目來說都是最重要的方面。
但現在不是了。他說，接著舉了Google Earth和Wikipedia這兩個典型例子，它們都是在發展中不進行多少控制的軟件。
為了說明他已改變了的推理，DeMarco引用了兩個假定的項目：最后都要花費大約100萬美元，但項目A將產生大約110萬美元的效益，項目B將產生超過5000萬美元的效益。
很明顯項目A會有更嚴格的控制，如果預算超支或軟件發布推遲或質量不達標，項目會冒很大的虧損風險。
相比之下，項目B由于投入和產出差異巨大，控制可以很松。很明顯的是，在這里面成本、期限和質量問題依然存在，但項目最終會賺錢。如果不賺錢的話，一切都會亂掉。
由此，DeMarco沉思自語道：實際上一位主管越是注重控制，他的團隊越是可能在開發一個只能艱難盈利的項目。
接著他說，管理軟件開發的問題應該不是關于嚴格的控制和軟件工程所規定的規律，相反，開發團隊應當開發產生真正效益的項目，主管應當降低對項目控制的期望。
這是在假設DeMarco以上第一個建議更關注企業領導者或分析師，因為是由他們確定一個軟件解決方案是必要的，而不是開發者被指派去編寫這些代碼。
普通公司里的程序員并沒有選擇他們開發項目的權利，但顯而易見，主管們應該在投入資源開發之前確定一個項目數量上的效益和質量上的效益，他們得在這方面多下功夫。
一個軟件工程之父，不停地在告訴人們要放松，不要整天盯著開發項目的成本和時間要求，這聽起來讓人感到困惑。
為了給他的觀點進行辯護，DeMarco拿青少年來做類比。對于青少年，你怎樣在他們身上找到一個人無法控制他不能測算的東西的理論依據？例如，一位稱職的家長會如何客觀地評價他子女的道德水平、教養和同情心？
在這種情況下，你無法控制一個撫養對社會有益成員的育人項目，相反，在軟件項目中你管理的是員工，控制的是時間和成本，從根本上說，在這過程中你得盡可能在擁有極少反饋信息的情況下掌控大局。
用同樣的方法，一支軟件開發團隊應當在開發過程中按照相關價值大小、文檔和測試結果不斷向項目中增加程序塊，在項目主管宣布項目完成的任何可能時候都能立刻將產品打包并發布。
DeMarco說，去設計規劃一套軟件依然有其意義，但那并不是軟件工程這個術語所要真正表達的意思，設計策劃軟件是一整套規則，過程，檢視，度量，規劃，追蹤以及許多其他元素的總和。
幾十年來，開發團隊們都在成本預算和時間限制上痛苦地掙扎著，但這不該是他們追求的至上目標。
更重要的目標是要轉變。DeMarco現在說，去切實改變這個世界或一家公司或它運作的模式才是更重要的。
幾乎是為了向自己推行了幾十年將工程化原則應用于軟件開發的想法表示懺悔，DeMarco說這場轉變是我們一向應該關注實施的。
在我個人看來，DeMarco說設計規劃一套軟件的做法與詞語軟件開發是不同的，這毫無疑問，的確，有很多人開始懷疑開發軟件到底是不是一種包含度量控制和管理控制的工程化實務，而事實卻是，軟件本身并不像物理學那樣有著堅實的科學理論基礎，而是充滿了抽象的概念，虛幻的構想甚至是一次次的試驗研究。
我職業生涯的美好回憶中就有自己提出的解決方案幫助公司進行重大轉變的一系列例子，其實謙虛地說，我的這些方案在技術層面上一點也不特別，但它們對公司起到的效果卻是立竿見影。這些直到現在我還能如數家珍般列出。
之前我說過這樣一個例子，在這個例子中我給那個老板設計了使公司的毛利率報表自動化生成的方案，這確確實實改變了整個公司的文化。現在，這是一個有著巨大甚至是無限價值的軟件項目。
具有諷刺意味的是，DeMarco的新式哲學有可能很早以前就存在了。2003年我讀了Ed Yourden所著的第二版《Deathmarch》（Deathmarch預示失敗的開發項目），驚異于其中一部分內容，在那里面，Yourden試圖界定適用于類似Microsoft Word這樣巨型開發項目的度量標準。
Yourden詳細敘述了他打電話給微軟，詢問軟件有多少行代碼的事，結果微軟技術服務人員在電話另一頭說不知道，他又問這個項目有多少開發人員，答復依然是不知道。Yourden繼續問著這些叫人無法回答的問題，最后那個技術服務人員火了：你難道不知道嗎？我們賣出了數千萬套軟件，誰管開發成本是多少？
當然，隨著今年早些時候的裁員，微軟也許現在會計算成本，但Yourden之類的作者們在最近十年早些時候肯定有證據表明項目的成本和可度量性會隨著回報率的升高而重要性降低。
我認為沒有人去超越這個觀點的原因是眾所周知的將軟件與已確定的工程化原則相關聯的必要性，盡管二者之間存在著明顯不同，比方說建造一幢建筑與開發一款文字處理軟件。
確實，有人經常說相比一門科學來說，開發軟件可能更是一門藝術，我越來越傾向于這種說法。我把它看成是一種工藝，一項技巧，一個創造過程。當編程理論能被教授時，它更像是一套音樂或繪畫的理論，除非你有天生的創造表現力，否則你不可能立志要成為有史以來最偉大的程序員或音樂家或藝術家。
與Agile Development嚴格的瀑布方法論和在它之前的應用程序快速開發（RAD）漸行漸遠的當代趨勢同樣支持了DeMarco的說法：實際上，他發現的事實已在我們身邊存在了很多年。
現在的問題是，沒人敢站出來大聲說：我們不再需要軟件工程這個概念！
【編輯推薦】
