假定乙個專案估算出來，乙個人做需要12個月（客戶哪能等那麼久，黃花菜都涼了）；那麼增加到4個人來做，是不是就可以3個月來完成呢，因為總共12個人月嘛。答案是否定的。
因為，如果專案真是乙個人來做，不存在溝通的問題，不會存在介面的問題，不會有這樣的場景出現：
專案經理：我們每週開個例會，討論一下目前的進度；
技術經理：來，討論一下設計方案；
程式設計師甲：這個需求好像不太明確，你自己弄清楚了再來找我；
設計人員：方案有變，得重新討論一下新方案；
程式設計師乙：我寫的程式沒問題，你呼叫的資料有問題；
......
其實，很多人一起做乙個專案，有點類似於現在多核時代的並行處理系統，有個阿姆達爾定律對並行系統的處理能力給出了定量的計算公式：
阿姆達爾曾致力於並行處理系統的研究。對於固定負載情況下描述並行處理效果的加速比s，阿姆達爾經過深入研究給出了如下公式：
s=1/(a+(1-a)/n)
其中，a為序列計算部分所佔比例，n為並行處理結點個數。這樣，當a=0時，最大加速比s=n；當a=1時，最小加速比s=1；當n→∞時，極限加速比s→ 1／a，這也就是加速比的上限。例如，若序列**佔整個**的25％，則並行處理的總體效能不可能超過4。這一公式已被學術界所接受，並被稱做「阿姆達爾定律」(amdahl law)。
專案由單個人完成，其實就是一種序列計算模式，一環套一環，一件事情接著一件事情完成；而增加到多個人來完成，就變成了平行計算，需要對工作任務進行並行化設計和分解，某些工作肯定是很難進行並行化的，而且工作任務需要同步，彼此協作才能完成這個專案。（有時候，系統的一些設計方式，就是為了方便多人協作，但往往會增加開銷）
假定我們需要序列工作的部分是20%，那麼上面乙個人12個月完成的事情，在增加到4個人時，會提速多少呢？我們用阿姆達爾定律公式計算如下：
s = 1 / (0.2 + (1-0.2) / 4) = 1 / (0.2 + 0.2) = 1 / 0.4 = 2.5 倍速
意思是說，進度是原來的 2.5 倍，那麼原來需要 12個月的，現在 需要
t = 12 / 2.5 = 4.8 月
比原來設想的3個月搞定的計畫要落後差不多兩個月時間。
那，有人說，那我繼續來增加人手，增加到 8個人來幹，總能更快些了吧？我們重新來計算：
s = 1 / (0.2 + (1-0.2) / 8) = 1 / (0.2 + 0.1) = 1 / 0.3 = 3.33 倍速 時間
t = 12 / 3.3 = 3.6 月
也就是說，新增加的那4個人帶來的效率，就是可能使專案再提前1個月完成。果真如此嗎？
我們前面假定a的值是20%，對於只是計算機執行的任務來說也許可以這樣來假定，但對於由人組成的「並行」系統呢？計算機的並行系統，比如使用多核處理器，每核的處理能力相同；但每個人的能力都是由差別的，對於專案人員配置，總是技術好的帶幾個技術一般的（甚至是學徒工），因此每個人對提速的貢獻是不同的。而且隨著人員的增加，溝通的成本會急劇上公升，由於模組之間介面增加，相應的缺陷也會急劇增加，因此 a 的值也會隨著人員的增加而變大。我們假定在 8 個人參與專案的時候，a 的值估計為 30%，我們重新來計算：
s = 1 / (0.3 + (1-0.3) / 8) = 2.58 倍速
發現這個結果與４個人參與專案時差不多，也就是說新增加的這４個人，除了增加了人員成本之外，並沒有帶來專案效率上的提公升。（也可以預計到，再增加人手，專案將會更慢更慢些）
這一點，毋庸置疑，增加人手並不能使專案進度加快到想象的速度，甚至相反，brooks 在《人月神話》中早就提及（有人也把此稱之為布魯克斯定律）：
brooks 人月神話 寫道
人月
人月（英語：man-month）指的是「乙個人要花幾個月」才能完成軟體開發的單位，通常用來評估一件軟體專案的大小。以成本會計（cost accounting）為基礎的進度預估技術，使我們誤把工作量和專案進度混為一談，人月是個危險並很容易就遭到誤解的迷思（myth），因為它假設人力和工時可以互換。
brooks法則
在乙個進度已經落後的軟體專案中增加人手，只會讓它更加落後。根據brooks法則，增加人員到乙個已經延誤的專案裡，等於是火上加油。除非你可以把工作區分，讓新進人員可在不影響他人工作的狀況下有所貢獻。
把工作切分給更多人做將造成額外的溝通（communication）代價——訓練和相互的交流（intercommunication）。欲增加軟體專案的人手，總共必須付出的代價可分為三方面：工作重新切分本身所造成的混亂與額外工作量、新進人員的訓練、新增加的相互交流。
網上也有人寫了文章來討論「布魯克斯定律」，比如：
柳記 **軟體開發定律系列之布魯克斯定律
下面的文章也很不錯：做乙個藝術品，只有乙個人才可以做好。規模龐大的工程，需要多個人來完成。
雲風的blog 軟體專案需要很多人一起完成可能是乙個**
關於分工合作
ｐｓ：為什麼會寫這麼一篇文章呢？因為今天剛好看到最新的《程式設計師》雜誌上的《1024核cpu上的並行程式設計》一文，突然想到在專案中好像也存在這種平行計算的影子。該文說道「同步所帶來的序列化開銷是並行程式最大的效能殺手」，同樣也可以說「溝通 所帶來的時間成本開銷是專案的最大進度殺手，但溝通是不可以省略的」。（當然，本文並不是否定團隊協作完成專案，因為大多數專案都不可能乙個人搞定：一是時間不允許，二是精力不允許，三是能力不允許，四是客戶不允許，五是......，最大的原因是
沒有必要也沒有能力乙個人扛，錢是公司賺滴，身體是自己的哦
）
為什麼不加人？
鄭昀 訂閱號 老兵筆記 最後更新於2017 8 31 以前我的口頭禪是 要人有人，要槍有槍，兵強馬壯，兵來將擋，水來土掩。最近兩三年不說這話了。改成了 公司的資源是無窮無盡的，隨時都可以就地招募起一支大軍。有了資源無窮無盡的幻覺，就會導致 最後來的事情最優先 既然最後來的事情最優先，後來的事兒隨時都...
為什麼索引會增加速度
首先明白為什麼索引會增加速度，db在執行一條sql語句的時候，預設的方式是根據搜尋條件進行全表掃瞄，遇到匹配條件的就加入搜尋結果集合。如果我們對某一欄位增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍歷匹配的行數，所以能明顯增加查詢的速度。那麼在任何時候都應該加索引麼？這裡有幾個...
為什麼插入buffer能夠增加驅動能力？
1 buffer是什麼？所謂增加buffer，buffer一般是幾級器件尺寸逐步增大的反相器或類似結構的電路，以使得電阻在獲得所需的驅動能力時，在功耗延時積上也達到最優。前後級的最佳驅動比例在2.718左右。buffer實際就是兩個串聯的反相器，常用於時鐘路徑中，用於增加時鐘驅動能力，使得時鐘clo...