Maxkit

2023/05/08

坎寧漢姆定律 Cunningham's Law

根據 Steven McGeady 的說法，在 1980 年代，Ward Cunningham 曾經給他一個建議：「在 Internet 得到正確答案的做法，並不是提問，而是先貼出一個錯誤答案。」McGeady 引述為 Cunningham's Law，這個規則正好是 Wikipedia 的運作法則，Cunningham 本人則否認了這個說法，認為這是錯誤的引用。

Ward Cunningham 在 1995 年於The Portland Pattern Repository's Wiki建立了第一個 wiki site，他也是 "The Wiki Way" 這本書的作者，該書討論 wiki 協作編輯系統。

像這樣的提問，都是 Cunningham's Law 的實踐

「5000元左右根本買不到好的遊戲本，全是水貨」
「根本找不到一個形容詞可以形容現時的政府」你同意嗎？
問小孩問題時
- 今天在學校做了什麼事情？
- 沒什麼
- 你今天翹課了喔
- 沒有啊，我們都在學校上課

用這個方法雖然可以快速得到答案，但也會有這樣的缺點：發言的人被認為是笨蛋。因此不要在正式場合使用，可在無聊時講垃圾話使用。

跟這個法則相反的狀況，有這樣的成語：眾口鑠金、積非成是、三人成虎、人云亦云

因此，這個法則並不能用在所有的問題上，只能用在可以確定，被提問的那些人，一定會有正確答案的狀況。當有人是用「聽說」來回答問題時，就可能會被錯誤的答案誤導。

2022年底也發生過這樣的事情：遭爆假街訪！哈哈台沉默5天回應　網破盲點狠酸：避重就輕│影片│造假│路人│TVBS新聞網

我自己也常看哈哈台，哈哈台的提問方式，就是用很多網路上的說法，來詢問當地民眾，如果把它當作綜藝，博君一笑，應該是沒什麼問題，但畢竟不可能每一次拍攝，都能找到一些當地奇人來回答，為了追求收視率，找臨演來拍影片，對當地人來說，被抓到也會覺得情何以堪。

不同的講者跟受眾，也會有不同的感受。看事情的角度不同，難免就會產生不同的觀點及感受。

難怪有很多專業的喜劇演員，私底下會是沈默寡言，常常會有憂鬱症的狀況。在很多衝突下，還要盡全力搞笑真難。

公視在 2022 也有討論這樣的議題：「你敢開身障者玩笑嗎？」

@hahaping ＸLeo @chairman1227 X王榮璋 X 雪莉@sherry0813 ｜「你敢開身障者玩笑嗎？」X 《禁忌不禁忌》｜〈公視主題之夜SHOW〉 - YouTube

References

【坎寧漢姆定律（Cunninghams Law）】到底是什麼？怎麼理解？ ? - GetIt01

【沃爾得英語】坎寧漢姆定律：“擡槓式提問” 、“茬架式求助”, battle啊！ - 雪花新闻

坎寧安定律 - Meta

沃德·坎寧安 - 維基百科，自由的百科全書

Cunningham's Law: The sun is flat, isn’t it?

眾口鑠金 [正文] - 成語檢視 - 教育部《成語典》2020 [基礎版]

2023/04/17

布魯克斯法則 (Brooks's Law) - 人月神話

Frederick P. Brooks, Jr. 於 IBM System/360 開發階段任職專案經理，OS/360設計階段任職軟體專案經理。在他管理的軟體專案經驗中，他將經歷寫成一本著名的軟體開發管理書本，名為「人月神話」。

在人月神話中，他提出一個觀念：在一個進度已經落後的專案再增加人手時，只會讓這個專案進度拖延更久。

在軟體專案管理中，有一些重要的事項，就是開發人力跟耗費的時間。這些估算工作，很多時候只能用經驗法則來判斷，由於這個估算無法非常準確，而且會隨著時間的前進，一直不斷地變化。

多數的管理人員都會用很單純的人月互換法則，來進行工作的估算，例如一個 10 人月的工作量，要直接分配給 5 個人用 2 個月的時間開發。

這是因為工作項目在切割的同時，就發生了項目的先後關係，且每一個項目在不同人員開發時，得到的成果跟品質不同，最後也會在整合階段，發生不同的問題，導致實際上不可能發生 10 人月 = 5 人 x 2 月。

一般在遇到進度延遲的狀況時，第一個反應會是增加人手，就像是蓋房子蓋到一半趕進度，就會想要從別的地方調派人力過來幫忙。但軟體專案沒有辦法依照這種想法處理，任意增加人手，很有可能會讓專案問題更亂更複雜。

造成這種現象的原因可能有：

專業工作無法任意切割
溝通成本大幅增加
新人無法快速融入團隊開發
舊人要暫停工作，做新人的教育訓練，需要更多時間，這些時間無法反映到實際的專案進度上

最明顯的實例，就是一個女人生小孩需要耗費 10 個月的時間，但十個女人生小孩，一樣需要 10 個月，因為這是一項專業工作，無法任意切割。

References

布魯克斯法則 - MBA智库百科

又delay了...為什麼人手增加後，專案進度反而死更慘? - Project Club 專案管理輕鬆學

專案管理你要知道事情布魯克斯法則 ( Brook’s Law ) | lalacube

浅谈软件开发定律系列之布鲁克斯定律_柳记的技术博客_51CTO博客

2023/04/10

阿姆達爾定律 Amdahl's Law

Amdahl's Law 是 1967 年 Amdahl 發表的論文提出的法則。

當時的命題是，在平行運算的研究領域中，一個程式可以分為可被平行運算與不能被平行運算兩個部分，當我們針對平行運算做效能提升的研究時，應該把時間跟經費做最有效率的投資，但究竟平行運算可以帶來多少效益？

\[ T = 程式以序列運算的總時間 \\ B = 程式中，無法被平行化運算的部分的運算時間 \\ T-B = 可被平行化運算的總時間 \\ N = number of Threads/CPUs \\ T = B + (T-B) \\ (T-B) 部分可被平行化，變成耗費時間 (T-B)/N \]

假設 T 為 1

\[ \text{if N=2} => T(N) = B + (T-B)/2 \\ \text{if N=3} => T(N) = B + (T-B)/3 \]

可得到程式運算的總時間

\[ T(N) = B + (T-B)/N \]

假設 T = 1, 只能序列運算的部分 B = 0.5, N = 2

\[ T(2) = 0.5 + (1-0.5)/2 \\ = 0.5+0.5/2 \\ = 0.75 \]

當 Thread/CPU 越多，就代表程式運算的總時間會減少。

另外有一個程式加速的指標參數

\[ Speedup = \frac{Original Execution Time}{Execution Time After Enhancement} \\ = \frac{1}{B+(1-B)/N} \]

如果程式有一半的部分可被平行化加速

\[ N=2, Speedup = \frac{1}{0.5+(1-0.5)/2} = 1.33 \\ N=4, Speedup = 1.6 \\ N=100, Speedup = 1.98 \\ N=1000, Speedup = 1.998 \\ N=10000, Speedup = 1.99998 \\ N=\infty, Speedup = 2 \]

意思就是，就算平行化運算可以無限的加強效能，減少運算時間，程式的總運算時間，會被無法平行化運算加速的部分限制住。

如果有兩件事，我們不知道應該去做哪一項時，也可以利用這個法則決定，取效益比較高的那一個。例如：讀書時不知道要先讀數學還是英文，先假設數學是無法提升的部分，算出 Speedup，再用英文為B，算出 Speedup，兩個互相比較，就可以知道哪一個效益較高。

但真實世界也不是那麼簡單的事，因為我們無法預先知道，最佳化後的成果，是不是跟預先假設的成果效益一樣。另外以讀書為例，我們也不知道一直都看不懂的英文，要花多少時間，才能改進並得到效益，反而是比較熟悉的數學還有進步空間，因為看不懂的東西，再怎麼看也不懂，就算看懂以後的效益很高也沒有用。