所有專案的失敗真的歸咎於程式設計師嗎？

今天，我讀到了兩篇有趣的文章：@unclebobmartin寫的The Cost of Code 和 @DocOnDev 寫的 Code as a Cause of Project Failure ，分別提供了這兩篇文章的中文翻譯，讀者可以分別在這裡和這裡閱讀它們的中文版。)。他們在用各種的論據來證明所有專案的失敗都是由於程式的原因。他們主要的論點是：如果程式沒有成本，輕巧易改變，專案就不可能失敗。是的。但這些是極端情況，很顯然在現實中是不可能的。我們並沒有生活在一個能夠時空穿梭的自由世界裡(很遺憾)。現實生活裡，程式是有成本的，而且很大，而且相信下個世紀也將會是這樣，所以這種論證證明不了什麼。

理想世界裡不需要程式。理想世界裡即使沒有計算機和其他複雜的東西，你也可以瞬間找到解決方案。所以我不認可他們的論據。在現實裡，程式不是專案失敗的主要原因。

程式是有成本的。程式是昂貴的。但我們並不是賣原始碼，我們賣的是解決方案。如果不需要程式程式碼就能產生解決方案，那是再好不過了。我們以一個處理現實目標的行業為例。汽車行業並不是出售碳物質和鐵塊的 – 那是汽車。他們出售的是一種解決交通問題的方案。時空穿梭機是一個理想的方案，但很遺憾，這種方式除了能傳輸電子外，什麼都傳輸不了。我們買汽車是為了能從A處到B處。我們買的是一種解決方案。

程式 != 解決方案

我認為失敗的專案的主要問題是他們要麼提供了糟糕的解決方案，要麼根本就不是個方案。沒有人現在還提供驛站馬車，那已經不是一種有效的解決方案。如果一個專案不能解決任何問題，它就會失敗。如果一個專案能解決某些問題，但做的很爛，不可用，那也是失敗。你可以用最簡潔的程式碼創造出世界上絕對最優美的架構。

你可以做到100%的測試覆蓋率，功能相互完全不依賴，繼承關係平滑，方法沒有二義。所有的優點你都具備，但如果你的程式不能有效的解決使用者的問題，專案仍然會不幸的失敗。

你也許會爭辯說，整潔的程式碼可以讓你快速的進行重構，一切都可以改變。但通常，如果程式解決了錯誤的問題，你需要完全重寫它。你不可能在驛站馬車上改造來使它跟汽車競爭。

另一方面，如果專案解決了正確的問題，但有缺陷，這時整潔的程式碼非常的重要。沒有整潔的程式碼你不可能做迅速的調整。但你不可能按人們的需求改變更多的東西。

別誤會我，我相信整潔的程式碼是很重要的事情，但在軟體開發的活動中它不是最重要的資源。