為什麼軟體更新這麼慢
你有沒有這個經驗，覺得為什麼軟體公司要加一個功能會這麼難，要花這麼多時間？我開始在YouTube購物打工時，就常常有這個感覺。客戶跟我們要新的功能，我們都要花好久的時間才能把它完成。我的組是負責把YouTube上面的購物紀錄做數據統計，譬如產品的銷售量、購買年齡層、最受歡迎的商品、最有銷量的影片等等。把這些數據整理好以後，我們會把這些資料呈現在一個叫「YouTube商家中心（Merchant Center）」的網站上。這個網站一般人是不曉得的，不過我們可以把它想像成是YouTuber網紅的後台，可以讓網紅了解頻道的經營狀況；「YouTube商家中心」就像是Walmart 等商家的後台，讓商家們知道他們的商品在YouTube上銷售的狀況。
所以，我們組的工作模式就是，每一季開始時我們會收集商家的意見與要求（Feature request），並決定哪一些是我們這一季必須要完成的。譬如，如果商家想要知道自家商品點擊量，那我們就要想辦法收集這些資料，並在商家中心網站上顯示。你可能會想，點擊量不就是一個數字？要在網站上放一個數字有多難？我一開始也是這麼想，做下去後才發現真的很難，一個人做通常要花數個禮拜才能完成，有些甚至要以月計算。我們可以把這項「點擊量」工作分成下面幾項步驟：
客戶要求文件（Product Requirement Document）
這個工作有時候就要花好幾個禮拜。首先我們要先知道客戶的要求是什麼？是要每一個商品的點擊量？還是每一個商品在某一個影片的點擊量？是要最高點擊的前十名商品？還是商品點擊率最高的前十個影片？還是點擊率最高的網紅？
再說，什麼是點擊量？如果商品在美國販賣，那麼台灣的網友點了要計算嗎？這種無效的點擊要分開算嗎？如果一個網友影片看了一次，但商品連結點了三次，那要算一次還是三次？影片中的連結點擊才算點擊，還是影片下方的描述中的連結也算點擊？短影片跟線上直播要包括在內嗎？通常跟客戶溝通來來回回就要花好幾個禮拜。
設計文件（Design Document）
一旦要求確定了以後，就可以鑽寫設計文件。也不是所有的任務都需要設計文件，但複雜的要求通常需要一個複雜的設計，而複雜的設計就需要一個設計文件，讓其他工程師可以審核、討論並批准。如果是點擊量，我們必須要知道這寫資料要從哪裡來？要怎麼存到資料庫裡？前端網站需要怎麼搜尋？等等。
設計文件通常在各種優缺點中作取捨。譬如，商家只需要前十名商品的點擊量，我們可以選擇簡化設計，統計出前十名的商品跟他們分別的點擊率，並存在資料庫裡。或者，我們可以統計每一個商品在每一個影片各別的點擊量，並把這些數據存在資料庫，然後再依據前端要求進行統計。前者的設計一下就完成了，資料庫也只存了十個數字，客戶開心，我們也開心。但後者的設定彈性更大，如果客戶改天決定要前一百名商品統計，或者前十名影片統計，後者的資料庫都能勝任，但設計起來更花時間、更佔空間和更花搜尋時間。
撰寫程式
設計文件在反覆審閱、吵雜的會議中終於定案以後，就可以終於開始寫程式了。寫程式其實不花時間，但等測試跟部署都很燒時間。測試是為了確定有沒有臭蟲，取決於軟體的複雜，有些系統測試甚至要以小時計算。測試完後就可以部署，部署就是把新寫的程式正式放進運作的軟體中，讓客戶可以開始使用。但是部署的頻率不一定，今天寫的程式，測試完後可能要等好幾天才會正式部署。那部署完就結束了嗎？並沒有，因為一個軟體系統有好幾個部署：有資料處理軟體的部署，網站後端的部署，前端網站的部署等等。網站的程式工程師，常常要等後端的部署完成後，才能開始測試網站；網站的後端工程師，則要等資料庫要資料後才能開始測試。所以一個人等另一個人、一個部署等另一個部署，常常整套下來就要花不只一個禮拜。尤其臭蟲發現越慢，成本越高、時間浪費越多。譬如極端的例子，當網站測試發現，客戶要的其實是「點擊率」而不是「點擊量」時，那就要從設計文件開始重新來過。拿半導體來比喻，這就像是晶圓良率已改善，正要量產時才發現電路設計有問題，十分悲慘。
批准
程式終於撰寫完畢（Code Complete），你正要慶祝關電腦回家時，你的主管提醒你趕快把會議約好約滿，批准程序才正要開始。有什麼樣的批准呢？譬如，網站是不是對色盲用戶友善，能不能自行朗讀，讓視覺不好的人也知道點擊量多少？這叫做無障礙測試（Accessibility）。點擊量有沒有經過適當翻譯？如果法國客戶在美國登入網站，網站上列的在德國賣的商品名稱，是要寫德語、法語、還是英語？這叫做當地化與國際化（Localization and Internationalization），其實這要在設計文件中就要交代清楚。如果點擊量只有1，客戶容不容易交叉比對，而知道這個網友是誰？這是隱私權審核。最後還要經過法律部門的審核，如果我們報了錯誤的點擊量會不會被告？整理了網友們的點擊統計會不會被網友們告？
兩個月過後，程式寫完了，該批准的該批准了，此時營運部門（Business Unit）發文下來，決定對該更新緊急喊卡：根據他們的研究發現，如果我們公布了點擊量，廠商們就會下架不受歡迎的商品，造成YouTube上面商品多樣性下降，不利公司未來長久發展。你看著Email，長嘆一聲，之前的工作都白費了，原來軟體更新真的好困難。