”符合程序員的邏輯，不符合人類的邏輯“ 一次和老總去吃飯，等了很長時間，飯菜卻遲遲沒有上來。我們倆都很生氣，這時候老總借景抒情的說：“我們做軟件的時候，就象開飯店一樣，要盡量滿足”吃客“的要求，盡管后來，飯菜還比較可口，但是因為等了老長時間，以后我們就再沒有去過那家店。。。。。。。

      一次和老總去吃飯，等了很長時間，飯菜卻遲遲沒有上來。我們倆都很生氣，這時候老總借景抒情的說：“我們做軟件的時候，就象開飯店一樣，要盡量滿足”吃客“的要求，盡管后來，飯菜還比較可口，但是因為等了老長時間，以后我們就再沒有去過那家店。
     作為一個程序員，尤其是一個水平比較高的程序員，他的思維邏輯一般是比較抽象。而在設計軟件的時候往往會出現想當然的想法。比如，在角色權限設計方面，一般情況，角色權限可以分為兩種1）針對行和列的權限策略，這種權限策略非常詳細。2)針對模塊的權限策略，這種權限策略比較寬泛。只是限制對模塊級別的訪問。兩種方法個有千秋，不能說那個好，那個不好，但是如果在錯誤的環境下應用了錯誤的策略的話，最終用戶使用起來可能就比較吃力。比如，在一個銀行系統中，出納可以查看客戶的卡號和帳戶余額，還有一些其他信息，而絕對不能查看用戶的密碼，此時如果采用針對模塊的權限，那實現起來就比較困難。而對于類似給一個規模較小，職責比較集中的OA系統來說，如果采用行，列授權，當然能夠嚴格保證系統的安全性和操作性，但這樣的環境一般不會有專門的系統維護人員，而系統配置起來，就可能比較麻煩。
這時候，我們復雜的實現也許給客戶帶來的是繁瑣和不解。最后相反會被一些簡單的系統所淘汰，就像java中間件里面，spring大有代替ejb趨勢一樣。同樣是權限管理，在授權的時候，可以單一為角色授權，另一種可以為角色授權，也可以為單獨用戶授權，從實現來說，單一為角色授權比較簡單，但是在使用的時候，由于設置權限的方法比較單一，用戶容易上手，某種環境下，可能比復雜實現的系統更加受歡迎。
   敏捷軟件開發宣言中有一句話：”相應變化，勝過 遵循變化“。原則中也有一項：”即使到了開發的后期，也歡迎改變需求，敏捷過程利用變化來為客戶創造競爭優勢“，其實這些都是要求我們以客戶的需求來設計我們的軟件。如果能在遵循需求的基礎之上，加上自己的經驗，設計出即簡單，又滿足功能要求的系統，那就更好了，但是千萬別單單評自己的直覺，設計出一些”符合程序員的邏輯，不符合人類的邏輯“的程序。這樣，我們可能很費力，但用戶還可能不喜歡。