People over Process (1)

April 28 22:28~23:52

幾天前指導教授拿了一篇 IEEE Software 上面熱騰騰剛出爐的 paper 給 Teddy 看：

People over Process: Key Challenges in Agile Development, July/August, 2011, IEEE Software, pp. 48-57.

自從畢業之後很少有時間去看 IEEE Software 上面的 papers，以前還在念書的時候，每期的 IEEE Software 上面文章 Teddy 都會快速翻過一次，看看有沒有值得看而且看得懂的文章。工作之後『國事如麻』，專案嗷嗷待哺，鮮少有時間定期去找看看有沒有值得讀的 papers。還好有善心人士介紹，這次才有機緣讀到好 paper。這篇 paper 是作者訪問了 17 個採用 agile methods 的組織，整理出這些組織在實施 agile methods 時遇到關於『人』的挑戰。這幾個受訪單位，採用的 agile methods 包含了 ：

• XP + Scrum：10 家
• Lean：2 家
• Crystal：1 家
• XP：2 家
• Scrum：2 家

由此看來 XP, Scrum 佔了大多數，給鄉民們參考一下。

接下來分幾天介紹一下 paper 中所提到的 『People challenges』，每一點 Teddy 都十分贊同。

Developer fear of skill-deficiency exposure 

第一個挑戰是『開發人員擔心自己能力不足之處被暴露出來』。Agile 團隊強調溝通與互相合作，一切講求透明化。套句古人所說的話：『知之為知之，不知為不知，是知也』。說來容易，做起來卻不簡單。試想一下，假設你到這間公司工作已經三年多了，某日你被要求與某個新進同事進行 pair programming，而且由你主筆。此時你可能心裡會想，糟了，讓同事知道我變數名稱取得很爛，我不太會寫 unit tests，或是我根本不會用 Eclipse 上面的 refactoring 功能....等等等。這種感覺，就好像是明天要期末考了，而你卻都還沒唸書。哇，agile 好可怕啊。

或是在每天 daily Scrum meeting 的時候，有一個實做 DAO（Data Access Object）的 task 你做了兩天還沒做完，此時你內心又會想，糟了，別人做類似的功能只花了五個小時，但是我寫了兩天居然還沒寫完，這樣別人不是發現我對於 database 不熟這件事了嗎！這豈不是又要動搖國本啊...XD。

又或者在跟團隊成員討論設計的時候，耶，怎麼別人開口就是『這邊可以套用 Observer pattern』，『把這個物件作成一個 Singleton』，不然就是『這裡要傳入一個 Collecting Parameter』，『這段程式要放在一個 blanket catch 裡面』。剛剛『花生』什麼事情，你們講的是中文嗎，我怎麼都聽不懂？

***

在傳統的軟體開發中，大家各作各的，雖然是同一個 team，但是在某些團隊中，其團隊成員的互動幾乎可以用『老死不相往來』來形容。既然別人不知到我在幹麼，這樣我的弱點就不會被發現。反正我每天也是都跟大家一樣加班到很晚啊，事情做不完我也沒辦法（Teddy 內心獨白：這個現象好像可以用濫竽充數來形容）。Developers 雖然付出加班的代價，但是獲得『保有自己能力不足不被發現』的安全感。受傷的是誰？一開始是專案進度，接著是公司，最後傷到自己。

所以要不要採用 agile methods？當然是寧死不從啊。為什麼？這樣我的缺點不是被大家看光光了，這和沒穿衣服上街有何不同，堅決反對啦。我們要爭取 司法人權 coding 人權。

解法呢？Paper 建議 provide an environment where developers feel safe to expose their weaknesses。Teddy 知道鄉民們在想什麼，這句不是廢話，的確是廢話。不過 paper 厲害的地方就是可以講得讓鄉民們覺的這是一句『值得購買的廢話』：

• 在受訪的 company C 中，開發人員每兩週將內心覺的不方便公開討論的議題寫在小紙上。但是關於這張小紙條要傳給誰 paper 居然沒交代...XD。
• 在 company D 中，資淺的開發人員可以自行決定是否在 stand-up meetings 中說出自以遇到的問題。
• 在 company B, D, M 中，資淺的開發人員另外還有一個特別為他們準備且時間較常的 stand-up meetings。在這個加長版的 stand-up meetings 中，有專門的 mentors 提供特別服務。
• 至少有九間受訪公司在實施 pair programming 時，採用『能力較弱開發人員』搭配『有經驗開發人員』的方式來提昇能力較弱開發人員的能力。

***

以上幾項，Teddy 只實施過 pair programming 這一項，非常有用。另外對於新人 Teddy 也會親自施予若干小時的『特訓』。還有一點，找人的時候如果能找到接受 agile 精神的人，那就可以省了許多功夫。剛好這一陣子新進的幾位新人都學過 Scrum，所以 Teddy 算是用到賺到，幾乎立即可上手。

***

友藏內心獨白：絕大部分的問題，幾乎都是人的問題。

還少一本書：零與無限大

April 26 22:02~23:20

Teddy 還真是個烏鴉嘴，幾天前在『一步到位還是一槍斃命？ 』才提到大陸高鐵，沒想到馬上發生了後車撞前車的『特大』意外事故。不過有一事 Teddy 不明，電視新聞報導時一直用『動車』這個名詞，這個詞翻成台灣的習慣用語，倒底是『火車』，『電車』，還是『高鐵』呢？

***

幾天前在 Facebook 上面的『Scrum Community in Taiwan』 社群中，有人問到「什麼時候不適合施行 Sc​rum 或 Agile」，Teddy 給了一個很簡單的答案：

關於『什麼時候不適合施行 Scrum 或 Agile』答​案其實很簡單：『看看自己的老闆，公司文化，團隊現況』​答案就出來了。我想台灣 99% 以上都屬於『不適合施行 Scrum or Agile 的公司』。以下是 Teddy 的想法：如果今天有人跑去天安門廣場大喊『XX黨』下台​，或是去利比亞首都大喊『XX費』下台，下場如何可想而​知。公司老闆不支持，team members 也不想了解，這都是常見的現象。除非想要導入的『那個人​』跟老闆很熟（老闆的兒子？）或是想當烈士，否則還是不​要導入為佳。

說實話，以台灣一般公司的文化與主事者的心態，說要去導入 Scrum 是極為困難的一件事。Teddy 曾經聽過一個故事，某公司的高高層對一位新進員工（高階主管）說：

不要把你在以前公司所做的那一套帶到我們公司來，我們公司有自己的文化與做事的方法，你自己要想辦法融入，不要試圖去改變。

Teddy 相信很多公司都是抱持著這種『排斥改變』的心態：好的，我了解了，你所建議的這個方法看起來似乎不錯，but I don't care。謝謝不聯絡。

***

這幾天 Teddy 在讀許文龍的『零與無限大』這本書，書中描述了許文龍先生經營事業的作法，其中有很多作法都與一般熟知的經營方式不同。也就是因為許文龍先生有著打破既有框架的勇氣，所以獲得了成功。舉幾個例子：

• 一般的公司與它的原料供應商之間，存在的都是利益衝突的對立關係。公司的採購想辦法殺價同時拼命的拿回扣，而原料供應商則不停的派 辣妹 業務來推銷產品。許文龍則是一次直接跟原料供應商簽訂 10 年的合約，至於價格則是由雙方來談（細節請參考 pp. 38-39）。總之就是想辦法將與供應商共享利益，把原本的對立關係轉變成非對立。
• 在公司創造一個『找答案，不找責任』的環境（p. 63）。Teddy 相信台灣絕大部分的公司，都是『找羔羊（代罪羔羊），不找答案』。
• 早在 1985 年，奇美公司就實施週休二日。為了彌補減少的工時，奇美投入千萬元更新自動化設備來因應（p. 68）。
• 經營，就是一種『適應環境的行為』...什麼事情都要到『現場』去講才準...在戰爭中，指揮官一定要到前線，才能看到地圖上看不到的東西（pp. 127-128）。
• 奇美可以說是一個『無文字的社會』...我們人一生的時間實在有限，用這些時間來做事，比較實在。人家問說，為什麼奇美一個人可以做那麼多事？我說：因為他們不用寫報告，可以一直做事（p. 132）。Teddy  內心獨白：好香好濃的 agile 味道...XD。
• 管理的事，真的是少做比較好。因為管理是成本很高的東西，為了管理，會使得整個工作效能都降低（p. 133）。
• 抽屜理論：政府要成功改造，必須先歸零（整理抽屜時，先把抽屜整個清空，再把需要的的東西挑進來）。現在的社會，並不是過去的延長。在科學跳要的時代，以過去的思考模式並不能解決目前的問題（p. 189）。

這本書有 399 頁，整本書的內容都十分精彩，有興趣的鄉民們可以去找一本來看。

***

許文龍是受日本教育長大的，他在書中說他曾經讀過一本日本人翻譯的『生態學』的書，受這本書的影響很大。因此他的很多思考模式，是從『整個生態』的角度來看，格局也就變得比較大。 Teddy 讀完本書之後，倒是看到很多 TPS（Toyota Production System），Lean 與 Agile 精神。天下的事，一事通，萬事通，也許這就是這個道理吧。

回到一開始的那個問題：『什麼時候不適合施行 Sc​rum 或 Agile』？Teddy 說，什麼時候都不適合，什麼時候也都適合。

***

友藏內心獨白：結尾那一句一定要搞的那麼玄嗎？

一步到位還是一槍斃命？

April 22 23:46~23:24

這幾年中國大陸的高鐵建設突飛猛進，從南到北蓋了有幾千公里的高鐵。從電視新聞的畫面看起來，感覺挺不錯的，平穩的車廂，高檔次的服務人員，以及還算合理的票價。但是，鄉親啊，電視是『聞不到味道滴』，此話怎說？

Teddy 的一位友人最近剛從大陸回台灣，友人從大陸南方搭高鐵到武漢，再從武漢搭到上海，也算是繞了大半圈的大陸。據友人表示，大陸高鐵雖好，但有一個最大的缺點：『煙味太重』。

Teddy 問：什麼，有人在高鐵上拜拜？ 大陸高鐵上可以抽煙啊？

友人說：不行，但是很多人跑到廁所抽煙。雖然車上一直廣播說不要在廁所抽煙，但是根本沒人理會。我搭的還是頭等車廂，如果是次一等的車廂，那味道可更多了。 在武漢的時候，還有人提著『鮮魚』上車，整個車廂搞得都是魚腥味。

Teddy 內心獨白：經常在早上搭 307  公車經過果菜市場的人，就能夠體會到整車都是『新鮮食材』味道的那種感覺了。

硬體可以幾內年建設完畢，人的習慣...終生難改。這一代是不可能了，看看下一代會不會長進一點。有辦法把人的水準搞到一步到位 Teddy 就佩服你。

***

今天看到一則新聞，說宏碁斥資近百億元台幣併購雲端公司 iGware（Teddy 內心獨白：這是什麼東東？），報導中說：

...評估雖然可讓宏碁在過去幾無著墨的雲端運算領域「一步到位」...

怎麼好像有種看到大陸高鐵的感覺...

***

友藏內心獨白：別鐵齒，誰說不會有人在『雲端上抽煙』。

多準備幾包吧

April 21 20:03~23:01

這個『包』，不是紅包，不是名牌包，更不是蒙古包，而是『軟體開發包』。

『軟體開發包』 是什麼包？話說 Teddy 自從開發了跨平台軟體之後，才發現原本開發跨平台（跨作業系統）的軟體已經是不簡單了，如果還和底層的硬體扯上關係，那就更是麻煩。例如，你的程式要讀電腦晶片組中的資料，而這個電腦上跑的可能是各種不同版本的 Windows 或是 Linux 作業系統，所以當程式開發完成之後，在這些不同的作業系統中測試你的程式是絕對需要的工作。有時候萬一發生問題，免不了可能需要在發生問題的環境中（例如，在 CentOS 6.0 x64 上程式有問題）安裝你的開發環境（例如 Eclipse）『就地觀察』發生問題的原因，如果能夠順便將 bugs 給『就地正法』那就更好了。

如果你的程式只要在某個型號的電腦上執行也就算了，萬一你的程式需要支援，例如說，30 款具有不同晶片組的電腦，那頭就大了。光是開發，測試與 debug 的『環境設定』工作就做不完了，怎麼辦？請老闆增加人手幫忙，想太多，不可能。加班，不但做不完而且品質與效率變得差，行不通。

***

之前 Teddy  讀了幾本 Lean 的書，其中提到 Toyota 之所以會成功的原因之一，是因為它的組裝線具備有『少量多樣』的組裝能力，並且可以達到接單生產與零庫存的目標（傳統的汽車組裝線都是『單一（或是少樣）產品，大量生產』以達到經濟規模為目的）。要做到『少量多樣』其實是很不容易的，因為工廠需要因應不同的產品而調整組裝線（調整機台，改變使用的工具，校對儀器等等）。學過作業系統（OS）的人都知道，這種 context switch 是一種浪費，過於頻繁的 context switch 甚至會造成『CPU 花在 context switch 的時間大於執行工作的時間』這種現象。所以，Toyota 想盡辦法改善組裝線，並採用自動化的方式將『調整組裝線』的時間降到最低，克服了這個問題。

有一天 Teddy 就在想，每次測試軟體功能，都要先安裝作業系統（準備一個乾淨的環境），然後安裝待測軟體（一直按下一步，下一步），然後手動測試想要測試的功能。後來用 Robot Framework 寫了許多自動化的功能測試，但是在一個全新的環境中要執行這些 Robot test cases，還是每次都要先把相關的工具都裝好（例如裝 Robot 本身，還有 Python 等等），也是挺不方便且花時間。Teddy 在『落實的能力 』裡面有提可以寫一些簡單的 scripts 製作『自動化功能測試包』，以綠色軟體的方式隨時佈署到待測平台上面執行自動化功能測試。長久下來所節省的手動安裝測試工具的時間是很可觀的。

最近 Teddy 又在想，有時候需要把整個開發環境從平常使用的開發機上面複製一份到有問題的電腦中進行 debug（當然也可以用遠端更新的方式來 debug，但是有時候直接在出問題的電腦中 trace 問題會比較容易）。問題來了，遇到這種情況，要把『整個開發環境複製一份到有問題的電腦中』有時候還挺花時間的，而且很容易出錯，丟三落四的，什麼該 copy 的檔案忘了 copy，該設定的環境變數也沒改到。所以，如果除了『自動化功能測試包』以外，如果能夠有『自動化開發環境安裝包』，自動安裝（自動解壓縮並執行一個設定的 script）之後就可以立刻開發軟體，那就更方便了。

除了上面 Teddy 提到的這『兩包』，還有什麼『包』可以讓開發軟體變得比較『順』一點呢？

***

友藏內心獨白：『自動化分散式 CI 包』好像也挺不錯的。

下一個軟體也許會更好...嗎？

July 20 22:15~23:10

如果有一天你接到通知，告知你即將繼承某個遠房親戚的 1 千萬遺產，你會有怎樣的反應？這種天上掉下來的禮物，在欣然接受之前，要先調查一下，這筆『遺產』到底是正數，還是負數。萬一不小心繼承了之後，突然有個債主跑出來說這位遠房親戚欠了他 1 億元，現在要你這個繼承人還債，那可就衰呆了。

『遺產』這種東西，做軟體的人是最了解的，三不五時就需要與 legacy code 搏鬥。這些 legacy code 可能是別人贈送的，也可能是『昨日的你』送給『今日的你』的禮物，總之通常收到 legacy code 的人都不會太高興。這些 legacy code 怎麼看，怎麼不順眼，最好是能夠砍掉重練，才沒有包袱。

最近學弟們要開發一個新的系統，雖然可以在某個既有系統上繼續開發（擴充既有系統的功能），但是學弟選擇了『另起爐灶』，理由很多，但沒卻沒有一個理由可以說服 Teddy 的：

• 原有系統因為某些架構上的限制，導致資料分別存在檔案與資料庫中，無法集中。
• 原有系統的資料庫是使用另一個系統所設計的 schema（與另一個 AP 共用相同的 tables）。受限於這個 schema，有些功能不太容易實做。
• 原有系統所使用的 Javascript framework 檔案容量太大，約 700 多 K（Teddy 內心獨白：700 多 K 會算 size 太大？！）。

首先先來盤點一下這個既有系統的資產負債表，首先看一下資產：

• 已經有許多使用者在使用這個既有系統，而且反應不錯。
• 最近一年多來既有系統有持續改善使用者介面的操作（提高 usability）與修正了很多個 bug，目前穩定性算是不錯。
• 開發既有系統的時候有寫 unit tests （test coverage 有待調查）。
• 開發既有系統的時候有做持續整合。
• 開發既有系統的人雖然即將畢業，但是在離校之前有問題都還是可以立即詢問（就算離校之後也跑不了太遠...XD）。

至於負債部份大致上就是上面學弟所說的那三點。雖然有負債，但是要償還這些負債並非不可能的任務，也就是說資產減掉負債之後該既有系統的『淨值』還是正數，而且是正很多的正數（每股淨值大於 10 元...XD）。

***

學弟們目前還無法體會『軟體是長出來的 』之精神所在，Teddy 十分相信 Andy Hunt 與 Dave Thomas 所說的：『All programming is maintenance programming』，如果能把心態調整一下，轉換成思考『如何用軟體工程的方法來償還這些負債』，那麼這段還債的過程，對於軟體開發經驗的提昇將會有很大的幫助。

開發『真正給人用的軟體』是一種承諾，就好像養小狗，小貓一樣，總不能說小狗小時候很可愛，就很疼愛牠。等牠長大發現怎麼變得不可愛了，就讓牠去『流浪』。當年有首流行歌曲叫做『下一個男人也許會更好』，也許吧...但是如果連『這一個軟體都搞不太好』，那麼『下一個軟體會不會更好』就很難說了。

越來越有一種感慨，開發軟體的『心態』比技術與能力都還要來的重要。『心態正確』可以讓你做對事情，而技術與能力可以讓你把事情做對。如果兩者都具備，那就可以準備上華山論劍了。

***

友藏內心獨白：好好照顧既有系統也算是一種節能省碳的表現 。

滿天是金條

July 20 00:30~01:18

台語有一句俗話叫做『滿天是金條，賣殺（要抓）沒半條』，這句話在不同的場合有不同的解釋，其中一種解釋可以用來形容有些人說起話來頭頭是道，意見很多，但是實際上做起事來卻是沒有一樣做得出來（沒有任何一個意見是可行的...這句話用來形容『顧問』倒是挺貼切的）。例如，鄉民們的主管如果是那種『說得一口好程式』的人，就可以用這句話來形容該主管。

不過今天 Teddy 要講的是另外一件事。上上個禮拜六 Teddy 去天瓏買了兩本書，其中一本是 Software Build Systems 已經在幾天前介紹過了，另外一本是 Martin Fowler 寫得 Domain-Specific Languages （以下簡稱 MF DSL）。今天晚上（已經過了 12 點了，嚴格講起來應該說是昨天晚上）擠不出什麼料所以想說不要寫部落格來看一下這本書。話說當天買這本書時 Teddy 小小掙扎了一下，這本書已經出了一陣子了，照理講 Martin Fowler 的書只要一出版應該要立即買來收藏才對，但是基於三個原因這本書 Teddy 卻一直沒買：

• 之前看過一些 DSL 的資料，覺的對於開發軟體似乎沒有立即的需要。
• 學會 DSL 似乎要花不少的時間。
• 這本書有點厚。

那一天不知道那根經不對就把書買回家了，剛剛看了 30 幾頁的感想是：這本書還真是好看啊。副作用則是害 Teddy 睡不著....

看了 MF DSL 之後才 發現 證實（因為 Teddy 老早就懷疑了很久了，只是一直苦無證據...XD），其實 Teddy 在 N 年前開發的某個核心程式早就在『重度』使用 DSL 了，之前 Teddy 看的 DSL 的書太 formal 了，所以覺的離『立即可用』有一段距離。Martin Fowler 果然不是蓋的，所寫得每一本書都有那種 『bridge the gap』 的能力。

***

剛剛 Teddy 稍微算了一下家裡書架上的電腦相關書籍，大概有 1000 多本，不過 Teddy 真的有熟讀的可能不超過 300 本，其他很多是買回來看了幾頁就丟著（資質不夠，讀不下去...），或是當作參考書之用（寫 papers 或是 proposals 會用到）。此時腦袋中突然想到『滿天是金條，要抓沒半條』這句話...

本篇的重點，Teddy 想講的是，到目前為止，有兩個人寫的書，Teddy 全部都買了而且讀過之後會有一種『戰鬥力向上提昇一級』的感覺，這兩位就是：Kent Beck 與 Martin Fowler... 真希望他們有空多寫一點書啊。

***

友藏內心獨白：有些書，除了拿來當『分母』以外，似乎沒什麼作用。 

聞過則喜...誰說的？

July 17 15:21~16:06
19:28~20:19

最近罵人罵得太頻繁，但由於考慮到『人情世故』以及怕走在路上被『蓋布袋』，因此罵的方式很間接，覺的不太過癮。此時 Teddy 突然想起了一則親身經歷的小故事。

話說 2004 年九月 Teddy 到美國參加 PLoP 2004 （Pattern Languages of Programs）研討會，這是 Teddy 第一次出國參加研討會，雖然有 Kay 同行陪伴，但是 Teddy 心裡還是滿緊張的。這個 PLoP 研討會鄉民們可能不太清楚，一般的研討會，輪到你報告論文的時間，大概也就是 15 - 20 分鐘。報告完畢之後，以台灣人這麼會善用時間的特性，一定是利用機會到當地去探訪一下風土民情，順便做一下國民外交（以上翻成白話文就是：到處觀光）。但是 PLoP 研討會是採用所謂的 writers' workshop 形式舉辦，有以下幾個特點：

• 投稿 papers 的作者，會被分成數個約 4 - 6 人的小組，研討會就是以小組討論的形式進行。
• 所有作者在參加研討會之前，就會得知自己被分配到那一個小組，並知道小組中其它成員。
• 在出發參加研討會之前，要讀過自己那一個小組其他作者的論文（原因等一下就知道了）。
• 每次討論的 session，以 Teddy 當年的例子，為 75 分鐘。在這個 session 中，只討論某一位作者的 paper。
• 討論會的開始，由論文作者先念一小段自己論文裡面最喜歡的段落。之後作者就成為『牆上的蒼蠅』，退居幕後聽其他的人如何評價你的論文。在這期間原作者不可以講話。
• 此時輪到其他人上場，大家先一起發表自己覺的該論文寫得好的部份，然後在說出覺的論文中需要改進的部份。

當年和 Teddy 同組的除了 Teddy 以外還有四個人，其中三位（兩男一女）都是美國大學的教授，另外一位男士是英國人。這位英國人後來將他的論文整理之後出了一本厚死人不償命的書：xUnit Test Patterns: Refactoring Test Code。現在想起來還有點好笑，因為當時有一位美國人還覺這位英國人『有些英文句子寫的有待改進』。

***

接下來的才是重點，這三位教授中，其中有一位就是寫 GoF Design Patterns 的第三作者 Ralph Johnson，此人就算是稱不上『大師』，但也算是有名的大牌教授。這個故事就是發生在他的身上。

就在某次輪到要討論 Johnson 的論文時，我們這個小組突然多出了兩位圍觀的鄉民，在此以鄉民甲，鄉民乙稱之。鄉民甲看起來是西裔美國人，鄉民乙則是白人。在會議進行中，這位鄉民甲感覺起來就是來拍馬屁的，一直稱讚 Johnson 論文（但不知其動機為何）。重點在於這位鄉民乙，因為這位年輕人是來踢館的。鄉民乙舉出了幾點 Johnson 論文裡面的錯誤（Java 程式碼的語法錯誤以及一些設計上的 issues），當場氣忿弄的有點僵。好在其他兩位教授以及那位英國人幫忙出來打圓場，說是『程式碼放到 word 排版很容易出錯』就這樣交代過去。雖然鄉民乙還想要繼續追打下去，但是畢竟勢單力薄，最後也只能見好就收。

那個 session 結束之後，Teddy 和 Kay 看到 Johnson 急急忙忙的跑去打電話，應該是打電話去罵他的學生吧...呵呵呵...Teddy 猜這論文應該是他學生幫忙寫或是排版的...。
 

***

Teddy 很是佩服鄉民乙的行為，因為鄉民乙所舉出 Johnson 論文中的幾點錯誤，的確都是『事實』。就算『只是排版錯誤』，但對於學術論文而言，也是很丟臉的事情，不是小學生寫錯字回家罰寫三遍就可以交代過去的。這種事要是發生在台灣...錯，假設不成立，根本不可能發生，台灣地狹人稠，大家動不動就說『相遇得到（修都A丟）』，誰敢那麼白目去揭穿『國王新衣』的秘密。

古人說，聞過則喜，但時代不同了，鄉民們不要傻傻相信。現在台灣普遍的現象則是：

• 官大學問大：反正當官的只要用一句『這是經過通盤考量之後的決定』就可以把所有的專業判斷全部打死。『通盤考量』翻成白話文就是說『老子就是要這樣幹，抗議無效』，是不是這個意思？就是這個意思....。
• 速食主義：凡事求快，要用最低成本達到短期目的。所以，新聞不必講求事實，只要報導那一家店在打折，那裡又推出新口味的火鍋，誰家的狗會唱歌，誰家的小強跌斷了腿又自行長了出來。其他內容只要把每天報紙上所寫的念一遍，加上從網路『翻拍』畫面加上配音說明，這樣就差不多了。難道台灣的新聞系上課都在教這些？
• 共犯結構：請自行發揮...
• 有關係就沒關係，沒關係就有關係。
• 為反對而反對：反正只要是非我族類，不管做的好不好，對不對，先罵了再說。可憐的楊大砲，沒事寫什麼書，最後落得一堆人想去告你。大陸人曰：不到北京不知道官小，不到上海不知道錢少，不到海南島不知道自己身體不好，不到台灣不知道文革還在搞。最後這句還挺貼切的。

寫到這邊有點離題了，不過反正本部落格一向以離題著稱...XD。昨天看了部電影，叫做『我的名字叫可汗（My Name Is Khan）』，片中男主角的媽媽告訴他，世界上只有兩種人，做好事的好人，和做壞事的壞人。不要分什麼回教徒，印度教徒，基督教徒，或是白人，黑人，本省人，外省人，台灣人，中國人。說得很好，但是有一個根本的問題電影中沒交代『誰來決定誰是好人，誰是壞人？』黑道漂白的例子可是屢見不鮮，好人做壞事的也是時有所聞。

***

看到有人用奇怪的方式去教導 Scrum，本和 Teddy 無關，反正害到別人也不會害到 Teddy。但是回頭想一想，如果悶不吭聲，Teddy 也很可能在其他自己不熟的領域，被其他人害到。台灣人這種『息事寧人』，『多一事不如少一事』的心態，要改過來還真不容易。連 Teddy 也變得有點『俗啊』，不敢指名道姓的點出有問題的文章。

布袋戲有一句很有名的台詞『互向漏氣求進步』，和聞過則喜的意義差不多。在現今社會，能做到的又有幾人？

***

友藏內心獨白：年紀越大，膽子越小，此為正常現象，請安心度日。