狗食文化
應該不少人聽過，M 社的研發團隊一直有一個習慣，就是在開發的過程中，就要開始在日常工作中使用開發中的半成品，稱為 "吃自己的狗食"。這個習慣的起源說法不一 (有一些趣聞和說明可以參考 https://zh.wikipedia.org/wiki/Eating_your_own_dog_food )，但很明確的是 M 社算是發起這個觀念的元老之一，而不是只是追隨者。筆者的印象非常深刻，剛進 M 社時就被指派做 Outlook 97 (當時的 code name 稱為 Ren，我到現在還是不知道是甚麼意思) 的 PM，最不能習慣的一件事，就是每十到十五分鐘程式就要當掉然後重跑一次，卻又不能使用舊的 MS Mail (不曉得還有沒有人記得)，不知道抓掉了多少頭髮。
特別要說明的是: 雖然當時有不少領導鼓勵這種作法，但是並不是一項既定政策，並沒有高層領導規定一定要這麼做。更獨特的是，要讓全研發團隊都吃狗食，其實是違反企業追求效率的原則，尤其在開發的早期，通常程式很不穩定，尤其是最常用的 Office 及 Windows，使用 dogfood 版本的作業時間會高出很多。但神奇的是，產品組都會不約而同的在開發的流程中加入 dogfood 使用的考量，而且自動自發地推動全團隊的狗食參與，表示這樣的作法具有一定的價值。
在學術上對這樣的做法和現象有蠻多的研究，評價上褒貶不一，有興趣的讀者可以去網路上搜尋。根據筆者自己的體驗，應該有以下幾項好處:
- 許多風險高的技術 big bet，可以在開發較初期的時候，就能決定能不能成 (所謂的 fail-fast)，不會拖到臨上市才很糾結把真的不能用的技術拿掉，降低試錯的成本。最有名的例子就是 Exchange 的資料庫架構，原本很早是希望用通用式的資料庫技術如 SQL來完成；但是在 dogfood 階段就驗證出來性能實在是跟不上，只好另起爐灶設計了現在的 EDB (Exchange Data Base)，一直沿用到現在。
- 應用在日常工作中，對於設計及除錯的優先順序的理解會比較深刻，而不是只是紙上談兵。在早期遙測功能還不成熟的時代，終端使用者的數據不容易直接取得，dogfood 使用者的資料是相對比較有規模的參考。
- 即使只是 M 社的內部使用者，還是會對產品組開發成品的品質造成壓力；產品組會想盡辦法盡早穩定化 dogfood 版本的可用度。
- M 社自傲的 inter-op (請參考 "網路外部性" 一節) 已可以在比較早期就進行測試，降低中後期整合的複雜度和測試成本。
當然，所有的措施有優點就有缺定，總有它的兩面性:
- 雖然不適用的技術淘汰的快，後面要翻身也變的很不容易，因為技術留下不好的評價。像 Exchange 使用 SQL 的例子，之後幾乎沒有人再翻案，雖然目前 SQL 進步的幅度遠大於 EDB，之前的顧慮早就沒有了。但是還是沒有人想要重蹈覆輒。
- Dogfood 版本用久了，產品組會太過習慣容忍並 workaround 產品的問題，而不是從根源去解決問題。而 M 社的內部員工終究與普羅大眾的終端使用者不同，無法完全代表。
- 太過注重內部使用者的意見，會對其它的設計產生排他性，變成只有 M 社的人會用，忽略了其他的情境。
- 太強的 interop，會造成 NIH (Not Invented Here) 症狀，意思是自己家的技術或是產品的優先及過高，跟市場上的要求不一樣。這一部分雖然不是 dogfood 直接造成的，但是有加強的效果。
到了 Web 2.0 時代，由於新技術的優點及快速疊代的觀念，"永遠 beta" 的做法越來越風行，dogfood 的做法對終端用戶的服務或產品就沒那麼重要了。即使如此，善用內部狗食，還是對企業導向的產品開發有一些好處，所以依我的推測，M 社內部應該還是有一定程度的實施。至於第三方的開發適不適合，還是要多一些考量: 例如公司內部的使用量大不大? 產品的屬性是不是符合等等，倒也不需要一頭栽進去。