軟件公司熱衷于雇傭喜歡挑戰技術難題的人。表面上看這種做法沒什么問題，不幸的是，這會導致公司處于一種情形，你讓他們開發一款產品，他們開發的產品更多的是來滿足他們對各種技術挑戰的好奇心，而不是用來解決客戶的問題。

　　自從看了在Quora上一個關于在Google工作和在Facebook工作有什么不同的問題的回答后，我就一直把這個事情記在心里。在其中，David Braginsky寫道：

文化：

Google像個研究院。人們喜歡挑戰難題，把問題解決。事情總是做的很完美，程序編的很堅固，每個系統從始至終量身定做。每種設計都有無數的專家，通過反復的研究審查確立。

Facebook更像一群未畢業的大學生。有些事情需要去完成，于是有人來解決。大多數時間他們并不去參考關于這個問題的各種文獻，也不去像專家咨詢如何才是“正確的”做這個事情的方法，他們只是坐下來，寫著自己的代碼，讓要做的東西可用。有些時候他們做的方式顯得很幼稚，很多時候存在bug,做成的產品不能用。當這種情況發生時，他們就去修復問題，把其中的瓶頸部分換成可伸縮性的組件，（大多數情況下）就這樣一件事情、下一個事情的做下去。

Google崇尚技術價值。事情被提出來做通常是因為有技術上的難度和能給人深刻的印象。很多的項目都是由工程師做決策。

Facebook崇尚產品和用戶體驗，設計師在開發中具有更大的影響力。Zuck會花費大量的時間注視產品原型，他對網站的外觀和給人的感受有更深入的關切。

　　Google因為成功的開發出了很多其他公司投入了大量的博士、計算機科學家都不能很好解決的軟件產品，給上千萬人留下來深刻的影響，受到了人們的贊譽。他們的產品并沒有按照上百人研究出的報告里推薦的那樣。我們很容易從它最近一些產品，例如Google Wave里，看到他們追求功能復雜的痕跡。

　　如果你回頭再去讀讀Google Wave 發布聲明，你會有趣的發現他們熱心于把各種不相干的功能組合到一起，喜歡把各種各樣的技術挑戰全囊括進來作為目標

• “Google Wave不僅僅適合即時通訊，同樣適合那些持久性的內容——它可以用來進行協調創造和交流”
• “它是一個HTML5應用，基于Google Web Toolkit，它包含了一個富文本編輯器和其他類似桌面拖拽用法的功能”
• “Google Wave 協議規定了底層的存儲格式和Wave共享的方法，它還包含一個‘即時’的并行控制模式，能夠使你的編輯的動作即時的反映給其他用戶或其他服務”
• “這種協議專為開放聯盟而設計，任何人的Wave服務都可以和其他人的進行交互，包括Google Wave服務”
• “Google Wave也可以被當作一個平臺，它有豐富的開放API，允許開發者們在他們的服務里嵌入wave”

　　這種產品聲明讀起來更像技術展示，而不是向人們宣告一個能幫助進行交流通信，合作，使他們的生活更方便的新產品。這是個極好的例子，一群聰明的人花了大量的時間解決復雜的問題但最終因為得不到用戶的反饋和支持而宣布終止開發。這是因為他們把大量的時間花在了技術挑戰上，而不是用在確保他們正在開發的是正確的產品。

　　所有的這些關于Wave的內部討論想起來很有趣，像他們把時間花在實現”字符輸入動作即使反映“功能時竟沒有人會起來提醒他們，在宣布Wave將會成為Email的替代品時，這種功能對于這個產品有任何的意義嗎？我經常寫email，用郵件發表一些評論，當我想把我的思想展示給廣大的讀者時，我編輯它，修改它，然后發送它。但我想沒人會像把這種創造過程也向人公布，沒人希望這種軟件功能。

　　XML又是一個例子

　　有些人可能會記得有一陣子我在微軟的XML研發中心的首頁上寫博客 。那些天里我大量的時間使用XML<->對象轉換不匹配這個詞來描述當時主要的Web service協議(例如SOAP)所使用的主要類型系統上有很多的概念不能和傳統的面向對象的編程語言（C#，Java等）很好匹配的事實。這是由于XML已經發展成為沖突的根源。有人把它當作的基本的文檔格式，例如 DocBook 和 XHTML。

　　有人把它視為一些用于交互式遠程過程調用技術使用的二進制協議的替代品，例如CORBA 和 Java RMI。W3C組織把一群聰明的人召集到一個房子里，希望他們創造出一種具有混合類型的系統來同時解決雙方復雜的需求。這次行動的成果就是XML Schema，它成為了SOAP、WSDL和WS-*族系技術的類型系統。這也就是說，如果一個人只想找一個簡單的方式來定義如何序列化C#對象，使之能被一個Java方法調用，那么他最終將使用的這種類型描述系統是一種同時也能描述這篇博客所使用的HTML的數據結構規則的類型系統。

　　像Sun微系統公司，Oracle，微軟，IBM和BEA等公司投入數千人數年時間在這些協議上開發各種工具來駕馭這種基本的技術。當然，除了這套協議之外，每個人都有自己的方式去解決XML<->對象無法匹配所導致的交互性問題。最終有些用戶開始爆出一些恐怖的使用這些協議實現交互的內幕，例如Nelson Minar的ETech 2005 Talk –在Google開發一個新的Web Service，并且，圍繞著提倡使用 Representational State Transfer (REST)來開發Web service 的運動自然而然誕生。一前一后的變化使開發人員們明白，如果你的問題是要傳送編程語言對象，那么一種專門為這種事情而設計的數據格式將會是一種更好的選擇。今天，你已經很難再看到廣泛的不使用Javascript Object Notation (JSON)、而使用SOAP的Web Service部署了。

　　這兩個故事的寓意都是要告訴我們，很多時候我們很容易迷失在追逐解決復雜技術挑戰的誘惑之中，因為我們強迫自己接受一種看起來是更有意義的設計路線，從而導致軟件復雜化，卻忽略了我們的軟件是要解決用戶問題的。避免讓自己處于這樣的境地，你應該評估一下如果改變你最初的設計會不會使的問題簡化下來，你應該盡量的花時間解決用戶的實際問題，取悅用戶。應該有更多的人捫心自問，我們真的需要使用一個相同的類型系統和數據格式來同時處理商業文檔和序列化編程語言對象嗎？

　　【英文出處】：

　　Lessons from Google Wave and REST vs. SOAP: Fighting Complexity of our own Choosing