多少年來，人們普遍有一種看法，認為軟體工程應該和其它種類的工程一樣：仔細的設計，精確的規劃，然後進行開發—嚴格按照設計說明書。就像修建一座橋樑，不是嗎？這種開發方式的問題在於：軟體，它是“軟”的。它可以無限的延展。任何需要的時候你都可以大幅度的修改你的軟體，人們也都是這麼幹的。還有，因為軟體可以被拿來對任何事物進行模型造型，你能要求軟體開發人員去實現的可能的東西幾乎是無窮無盡。想要在軟體裡模擬積體電路嗎？幹吧。想管理銀行？沒問題。讓五億人和他們的朋友保持聯絡？為什麼不呢？小菜一碟。不僅如此，在開發的中途我們還能要求程式設計師去做各種修改，這種事情經常的以一種不可預期的形式出現。
這可不是像修橋那樣。
由於漠視這種需求不斷變化的現實，多年來，無數的專案要麼慘遭失敗，要麼鉅額超出預算。所以，在總總的各種證據面前，整個行業為什麼還要堅守這種錯誤的認識？很難說為什麼。不過，最終，行業裡開始出現一種新的認識：軟體開發工作應該更好的響應需求的變化。事實上，為了適應這種需求上的變化，我們應該改進軟體開發過程。沒有比如今的web創業開發社群更歡迎這種趨勢的了。所謂的敏捷開發方法已經開始流行，“lean start-up”運動號召對執行中的系統進行自動的或依據經驗的超常快速變更響應。
所以，我們都是好樣的，不是嗎？雖然行動的不是那麼快。儘管有越來越多的敏捷開發方法被人們接受，仍然有大量的傳統錯誤認識遊蕩在我們周圍…這些認識大部分都該丟到腦後。
1. 誤解：你應該招聘一些“日本忍者”式的程式設計師。
對程式設計超人的迷信是矽谷創業公司中最普遍的一種病症：一個孤僻的程式設計師，以匹薩和咖啡因為能量，頭戴耳麥，通宵不倦的開發一個複雜的系統，所有的東西都自己一個人來幹。時過境遷了。軟體開發已經發展成一種團體運動。所有的創業公司只要獲得了任何有意義的成功，都會成長起來。一個程式設計獨俠客能夠勝任的情況放到一個10人的公司裡後就不可行了。而且，更糟糕的是，鼓勵逞英雄的行為會在開發團隊裡產生腐蝕性的機能障礙。始終如一的朝九晚五、日復一日編寫出公司賴以生存的穩固功能程式碼的程式設計師，輸給了能以通宵加班(通常只是一晚)來期望獲得慷慨的褒獎的精明極端利己主義者。與其獎勵這種英雄，不如培養出真正具有團隊精神的員工。
2. 誤解: 程式設計師需要安靜的工作，避免打攪。
讓人們獨自的幹活，這個聽起來很有道理 。每一次的打擾都是切實的中斷你的思緒，而且你需要花很久才能重新找回那種“狀態”。有些著名的軟體公司甚至堅持要為每個程式設計師安排獨立的辦公室。他們這樣就不會被打攪了，是嗎？除非現代新形式的干擾並不會像一個真人拍你的肩頭時引起你的分心，比如即時聊天工具，移動手機，Facebook，Twitter，電子郵件，以及從程式設計師頭上戴的耳麥裡傳出的用於幫助集中精神的音樂。現實情況是，大多數的獨自工作的程式設計師每天只花一小段時間用於真正的程式設計：各種形式的干擾事情層出不窮，整天他們都在進入狀態和失去狀態的迴圈中來來回回。然而，有個辦法能解決這個問題：結對程式設計。兩個程式設計師，一臺電腦。沒有Email，沒有Twitter，沒有手機電話(至少沒有無計劃的電話；你可以在有規律的間隔休息時間裡處理這些事情)。如果按照這樣做，你會收穫一個完全程式設計的一天。而且，和他人一起工作，“進入狀態”的過程幾乎完全不費時間。這是一種完全不同的工作方式，我深信這種方式的效率遠高於獨自工作的形式。事實上，針對當前的辦公室裡的這些“電子裝置引起的注意力分散”情況，我認為這是能讓軟體開發團隊獲得最高效率的唯一辦法。
3. 誤解: 創業公司競爭激烈，所以每個人都該幹到精疲力竭為止。
沒白沒夜的加班加點並不能讓你做的更多，做的更快。事實上，這會讓你適得其反。不錯，你覺得一週就能完成。但大部分的創業公司的開發計劃都會比這個長，程式設計師通常需要持續幾個月的進行開發(如果不是幾年的話)來成功的完成一個產品。很多創業公司的行為表現就好象是這罐金子就放在那個牆角，只要能再努力一點就能拿到它。很快，開發人員的精力就被榨乾了，如殭屍一般只是做出在加班的樣子，沒有任何的工作效率。高強度的工作，只是從短期來看會獲得更多的工作效率。著名的開發公司Pivotal幫助過成百上千的創業公司開發過系統，從來都是嚴格按照40小時工作日來完成任務的。
4. 誤解: 工期緊必然需要走捷徑。
很多團隊都以市場壓力大、需要立即釋出產品為由，寫出劣質的程式碼。寫出的測試程式繞開問題部位；瘋狂的攻堅衝鋒中認真設計原則被拋在腦後。但是，作為各個軟體開發團隊，大家都一樣。高效能的團隊在成功之餘不失英雄本色：正相反，當壓力出現時，他們巋然不動，以自身深厚的功底成功化解任務。我們無數次聽到過高壓下出高成就的傳奇故事—要麼是軍事行動、專業運動，要麼是飛行員在河上強行降落—其中的原因無非是英雄們的那句話，“我們受過專門訓練”。
5. 誤解：開發人員應該全權負責自己的程式碼。
負責自己的程式碼，聽起來很正確。理所當然的。個人職責嘛。可是，開發團隊裡在程式碼上分配歸屬人就意味著每個模組的程式只有一個開發人員來寫，只有一個人能掌握。這會導致負責模組的程式設計師之間產生“地方保護主義”。對於公司老闆來說，這造成了很大的風險，因為團隊中損失一個人就會影響整個團隊的程式，如果這個人是負責系統的關鍵核心模組的，那更會造成公司業務癱瘓。健康的工作方式是讓每個程式設計師都經手過系統內的所有程式碼。結對程式設計能讓你實現這個效果，知識會從一個人傳遞到另一個人。所謂的“巴士指數”(團隊中的多少人被車撞才會導致大家都無法進行)是一個軟體創業公司的關鍵風險指標。我們這裡所說的不僅僅指的是巴士在使壞，還有你的競爭對手，他們樂衷於挖走你最好的程式設計師。理解整個系統的人越多，你的公司就越健壯，越有活力。
6. 誤解：你需要一個怪異的招聘過程。
你會在僱用一個演員時不進行試鏡嗎？如果要試，你就能短暫的做一回導演。這正是如今幾乎所有的公司在招聘程式設計師時會出現的場景。通常的面試都會談論應聘者的經驗。這就完了。你可以想象一下，問一個躊躇滿志的演員是否喜歡飾演哈姆雷特這個角色。你能傳神的扮演他嗎？好的。你被僱用了！很多著名的軟體公司喜歡給應聘者出腦筋急轉彎題。有些頂級的公司甚至給候選人進行IQ測試。他們中最可取的是在白板上模擬軟體問題，讓候選人解決。這些情況讓人很無奈。我要說的是這非常明顯的道理：招到好的程式設計師的唯一可靠的方法就是跟他們一起程式設計。我對程式設計師的面試是跟他們進行一個小時的快速的結對程式設計—而且這只是面試的一個開始。大量的篩選，把他們按滿分100打分。什麼樣的會被選中？思維敏捷，抽象思考能力強，掌握各種演算法，問題解決能力強。而最重要的是，領會能力。因為協作是對團隊來說最重要的東西，如果你不能理解其他人是如何思考的，再聰明也沒用。
編注：原作者Tim Ferriss的觀點和Alan Skorkin一模一樣，Alan也是建議把這些技術開發人員放到他們所處的位置上，然後後退，觀察他們。觀察他們如何工作、如何跟別人交流，以及別人如何跟他們交流。請參見《面試開發人員的有效方法》。另外，也推薦看看《高效的面試方法：結對程式設計》。
7. 誤解: 專業化很重要。
非常自然的，管理者遇到問題時習慣把問題分解，各個擊破。在開發團隊裡，這通常慫恿技術人員專項發展。前端開發， 後臺開發，資料庫管理員等等。Brad Feld 在他的部落格裡建議說，每個團隊裡都應該有個“全能程式設計師”，這個人是個真正的通才。他是對的，但他說的還不夠。每個團隊裡的每個成員都應該是通才全才。為什麼？因為專才導致團隊脆弱。還記得“巴士指數” 嗎？每個專才都是一個弱點；如果他離開了，你找不到替代他的人，你完了。不僅如此，它還能使團隊機能失調。專項的人需要把他們負責的系統裡相互獨立的模組通過定義好的介面相互通訊。事實上，他們每人都寫出了各自不統一通訊方式。這導致了大量的額外開銷，經常會出現“地方保護主義”或相互指責。而在著名的 Pivotal公司，每個程式設計師都要接觸到系統的各個層面，從HTML和JavaScript到Ruby，到資料庫。而有些人認為專才會在系統的某個層面上更專業的，這種說法未必站得住腳。如今的軟體技術變得已經不是那麼複雜了。程式設計師能更容易的掌握各個層面上的知識以及如何操作它們。順便說一下，這暗示出了另外一個非常重要的資訊：你不再需要為某個特殊的技術而招聘人才了。缺少Ruby程式設計師？好，招一個Java程式設計師，培訓他使用Ruby(這裡使用結對程式設計格外的有效)。有些人稱自己為“伺服器端”程式設計師？沒問題，讓他們寫JavaScript程式，他們很快就能學會。
如果他們是人才，那就體現在這裡。
原文：Tim Ferriss
譯文：外刊IT評論