80/20法則下的設計

為了增加80％的彈性，而提高20％的複雜度，我們都能認同，但如果需要很高的代價才能彌補不足之處，就是該取捨之處。
軟體的設計從某種角度來看是一門藝術。就像是大師的設計，有時實在會讓人不禁感嘆其精巧及絕妙。可是，除了具有藝術的特質之外，從別的面向來看，軟體設計同時也處處充滿了需要算計的現實問題。
在我們的開發經驗中，時常會提到「軟體工程」這個名詞。雖然軟體開發本身兼具科學及工程的特性，但是當我們用工程而非科學的角度來檢視軟體開發時，該項觀點所重視的實用性，就會變得相當重要。
若我們用工程的觀點切入來看軟體設計的工作，軟體設計的工作基本上是一門「取捨」的學問。這個領域經常面臨許多實際上的限制，例如時程、人員、硬體設備的等級、產品的規格、需求的範圍、維護的難易與否……，這些都是實際面臨到的各種限制。
想要面面俱到，現實中難以達到
就拿極限編程（eXtreme Programming）來說吧！在這個開發方法中認為，影響到軟體開發有四個主要的因素，分別是成本、規模、時程、品質。這四個主要的因素之間相互交錯影響，只要更動了其中之一，很難不同時牽動其餘三者。例如，想要縮短所需的開發時程，就一定得投入成本、或者（並且）縮小規模、或者（並且）降低品質。
善用80/20法則，發揮以小博大效應
「80/20法則」又被稱為「帕雷托法則（Pareto principle）」，維基百科上對這個條目的解釋是：「在眾多現象中，80％的結果取決於20％的原因」…例如，在電腦系統中，80％的資源是由20％的活動所使用，所以想要最佳化對這些資源的使用，就必須針對這20％的活動來著手。有些人將80/20法則稱為「最省力法則」，因為80％的收穫源自於20％的努力，其餘20％的結果卻必須付出80％的力氣才能獲得。善用這種因與果之間不平衡的自然現象，就可以發揮以少博多的槓桿效應。