看到 command 提到《Don't Fall in Love With Your Technology》，而有一些感觸。
從高中開始，我一直想弄明白 Perl、Python 到底那一個比較好用，這樣我學其中一個就可以了。後來又多了 Ruby 這個選項，讓這問題變得更複雜。大概到大學後期或研究所的時候，我才肯定這是一種信仰上的爭辯，而將這個問題拋之於腦後。
同一時期，我也花了滿長一段時間才明白許多問題沒有標準答案，得視情況而定。每當對此有所體會時，就會想起大學電子學老師整年重覆強調的一句話：「沒有前提，就沒有答案」。雖然兩學期的電子學都是低空飛過，這句話深深印在心裡，只是那時我對這句話的理解仍不深，還需時時重新琢磨它的含意。
我花了更長的時間才將前面兩個心得連結在一起，從而明白任何工具或方法的爭辯很可能都是偽命題，重點在於需求是什麼？要如何滿足需求？如今回想起來，《不要自称为程序员》將這個觀念解析得相當清楚，相當值得一看。
舉例來說，「vim vs. emacs」是個偽命題，這取決於自己當下的環境為何。若團隊內多數人使用 emacs 且自己兩者都不熟，那麼 emacs 是較為合理的選擇。反之，若自己相當熟 vim 而團隊內多數人兩者都不熟，那繼續使用 vim 較為合理。重點在於「如何有效率地在自己的環境下解決問題」，而非「一般而言，那一個編輯器比較強？」
再以軟體開發的方法來看，「agile vs. 某個軟體開發方法」也是偽命題，不論 agile 公認的定義為何，重點在於滿足需求，而滿足需求不見得需要一套完備的軟體開發方法；有完備的軟體開發方法不見得能滿足需求。要滿足需求有太多事要做，研讀相關技術、軟體開發、市場行銷等，軟體開發可能是滿足需求的其中一項基石，但不是全部。若滿足需求的前提需要改善軟體需求，自然需要改善它；反之則否。《Joel on Software - 別讓架構太空人嚇到你》對「開發軟體的方法 vs. 滿足需求」提了生動的描述。
舉另一個具體例子，「是否需要重構？」往往帶來許多爭議性的討論，各方人馬（PM、RD、QA、...) 對此有不同看法。若這段程式一直都不需要加新功能，那的確不需要重構。重構只會花費時間讓程式碼變漂亮，對於滿足需求沒有任何影響。反之，之後需要繼續大幅加功能，逐步重構部份功能，則對完成產品（滿足需求）大有幫助。
最近幾年有一個很紅的議題，開發網站是用 Ruby on Rails 好，還是用 ... 好。最近一年可能還會多一些人問是否要改用基於 node.js 的新 framework。要回答這問題得先看需求為何，若只是做幾頁的小網站，用什麼方法差異都不大；若是做長期維護的大網站，要看目前團隊成員熟悉的工具和程式語言為何，再來評估使用 Rails 的相對成本。若再涉及和後端整合，又和既有的 code base 有大幅關聯。而要回答這一切一切衍生的議題，還是得先看：究竟需求為何，基於什麼原因而採用 X 會更好？以 Justin.tv 為例，《Django: Why is Justin.tv porting their codebase to Django from RoR?》說明 Justin.tv 轉換的主因是全部程式都是用 Python 寫的，此外，他們也想藉機重新設計一遍架構，去除 legacy codes，以符合現今的使用需求。
舉這些例子的用意不是無限上綱地說工具和方法都不重要，而是強調將焦點放在如何滿足需求，若有需要選用好工具，才有必要討論它。問錯問題的話，永遠不會得到有用的答案。
