最近時常想到 The Effective Engineer 裡面有一章提到的－Validate Your Ideas Early and Often（隨便翻：儘早、經常的驗證想法），介紹的第一個例子是曾經有一家可能被視為 Google 搜尋引擎競爭者的公司 Cuil，當時宣稱有超過 12 億的網頁被索引，是 Google 的 3 倍多，Cuil 也是花了幾年的時間在開發爬蟲、索引，因為當時（約 2008 年）沒有普遍的雲端主機服務像 AWS，所以也自己利用硬體資源建立幾千台的伺服器 infrastructure。但是他們在發表之後遭受許多知名媒體的批評，像是 PC Magazine 用了 “buggy”, “slow”, “pathetic” 的字來形容，在上線的時候，Cuil 的服務遇到了多次當機，最後，Cuil 失敗了。
書中提到幾點 Cuil 失敗的原因：
- 沒有雇用 alpha 測試者來試用產品
- 因為當時 Cuil 擔心發表的內容會被洩漏出去，所以他們也沒有像公司外面取得 feedback 來指出搜尋結果的問題
- 與 Google 相比，Google 花了很多心力在處理為了高搜尋排名的垃圾網站（按：現在卻一堆內容農場…），但是 Cuil 沒有任何人在處理這個部分
看到 Cuil 的經歷與書中提到的幾點問題，簡單來說有一點是他們沒有在開發產品時盡快的驗證產品的做法是不是有問題，需要調整的地方。
之前的工作，其中有一個專案是開發管理志工的系統，自己花了很多力氣在系統開發，默默地寫了實作程式、測試程式、建立自動化的腳本，把開發流程跟 CI 結合，完成後，老闆才發現需要修改與實作的功能不是他們想要的。回想那段時間，當每週開會，老闆問到專案進度，只是告訴老闆完成了哪些部分，或正在開發、快完成了，到接近預計時間，才把自己認為完成的成果給老闆或同事看，在那個時候，才發現在實做出來的功能或做法，跟其他人原本認爲的完全不一樣。過一陣子回想起來，在每週開會的時候，要向老闆 demo 開發的功能，來確認實作的功能是不是走在正確的軌道上，也能夠讓老闆對完成後的系統有更清楚的了解。