原文：《Hype Driven Development》，感謝原作者 Marek Kirejczyk 授權翻譯，感謝 CH Huang、Yi Jeng Lin 協助勘誤。轉載請附上原文連結與出處。
軟體開發團隊時常靠偏見、社群媒體上的消息、或者只是看什麼東西最「夯」來決定要用什麼架構或是技術。而非扎實地研究與衡量這些東西對專案會造成什麼樣的影響。我把這叫做「一窩蜂驅動開發」（Hype Driven Development），我認定這樣是有害的也建議開發者們改採更專業的「務實軟體開發」（Solid Software Engineering）。我會解釋這一切是怎麼發生的，還有怎麼避開這個問題。
新技術－新希望
你經歷這樣的情況嗎？有個團隊選了個最新最酷炫的技術然後直接頭洗下去。可能是因為某個成員讀了某篇部落格文章、 Twitter 上面最近也討論很兇、然後有些人剛從研討會聽了一場關於這個新技術很棒的演講回來。過沒多久，團隊便開始使用這個閃亮亮的新技術（或是某種軟體架構）。但開發效率跟成果沒有像其他人宣稱地變好，整個團隊反而陷入麻煩之中。效率降低、士氣開始低落，然後下個正式版本的交付陷入窘境。有些團隊甚至忙到沒時間出新功能都在修 bug，他們總是說「還要再幾天」才能找出根本問題。
一窩蜂驅動開發
一窩蜂驅動開發有著各種不同的樣貌，對你的專案影響也不盡相同。
- Reddit 驅動開發－團隊或個人是靠知名部落客現在在寫什麼、Reddit 在討論什麼、Hacker News、Twitter、Facebook、GitHub 或是其他任何的社群媒體來決定要用什麼技術／架構／設計。
- 研討會驅動開發－當團隊成員從研討會回來的時候要特別小心。通常他們會得到很多啟發，但這是兩面刃。在充分地研究之前冒然採用最新最夯的函式庫／框架／架構是通往地獄的特快車票。
- 講話最大聲的說了算－某個人雖然沒用過某個框架／函式庫／技術但是卻一直在傳教，然後有一天團隊被說服了而採用這個新東西。
- Gem／函式庫／外掛驅動開發－這在 Ruby on Rails 的社群特別常見，很多 Gemfile 的長度長到只有載入時間可以比它長。因為他們認為所有 Rails 上遇到的問題都該以引入 Gem 來解決。有時候問題只需要自己動手寫幾行程式就能解決，但我們總是想要用別人的函式庫、外掛、Gem、框架去解決。
- 然後我想岔題提個一窩蜂驅動開發者常見的症狀－Stack Overflow 驅動開發－他們從 Stack Overflow 或是其他網路資源做複製貼上的動作而沒有去理解問題與解答。
一窩蜂是開發團隊自我毀滅的原因
問題在於一窩蜂會造成錯誤的決策。架構設計錯誤與技術選用錯誤都會困擾團隊數個月甚至數年之久。最壞的情況會造成另一個很糟糕的行為：砍掉重練，這樣做永遠不會有好結果的。
一切的罪惡根源似乎是社群媒體，太多的想法在實戰測試之前就傳出去了，跑得比大家分析利弊得失的速度還要快。
剖析一窩蜂
大多數的一窩蜂現象有著類似起伏：
第一階段：真正的問題與解答
一開始是某個公司遇到某個問題。公司裡的某個團隊認定現有的技術、流程、或是架構設計無法解決他們的問題。這個公司自製了一個架構、函式庫、或是設計模式解決了他們遇到的問題。
第二階段：曝光、瘋傳、關鍵字
這個團隊迫不急待地想跟其他人分享他們的解法，過沒多久他們開始寫文章，去研討會演講。他們解決的問題通常有一定的複雜度，所以提供的解決方法也會有一定的複雜度。人們對新技術感到興奮，卻不一定對問題本質還有解答的實作細節有深刻了解。畢竟問題跟解答都不簡單，一個推文、一段閒聊、甚至一整篇部落格文章可能都沒有辦法解釋清楚。當我們用社群媒體、部落格、或是研討會上的快閃演講來傳達，訊息本身就失真了。
第三階段：狂熱開始
各式一窩蜂的開發者讀到那些文章或是聽到演講。很快地世界各地的開發者都開始採用這個新技術。但因為他們接收到的訊息有一定程度的失真－有些人倉促地決定使用某個框架，即使這個東西並沒有解決到他們現在實際遇到的任何問題，但他們還是錯誤地期待這個新玩意兒是萬靈丹。
第四階段：失望
過了幾個 Sprint 之後，這項新技術並沒有讓團隊過得更好，但他們要花的工夫變多了。團隊要花很多時間重寫程式還有學習新技術要怎麼用。整體進度慢下來了，管理階層覺得火大，大家都覺得被騙了。
第五階段：多麼痛的領悟
終於，團隊在事後檢討的時候領悟到要採用這項新技術是需要取捨的，然後其實應該用在哪個情境會比較合宜。他們學乖了⋯⋯直到下一個很「夯」的東西出現。
一窩蜂的例子：
底下是一些現實中一窩蜂的例子，看看它們發展的歷程。
範例一：React.js
第一步： Facebook 遇到一個問題－有些複雜的單頁應用，像是 Facebook 本身，有著大量會改變狀態的事件。會變得很難去追蹤到底觸發過什麼事件或是很難確保程式的狀態保持一致。
第二步： Facebook 開始推廣新的設計，夾帶著一些關鍵字：函數式程式設計（Functional）、Virtual DOM、Components。
第三步： 狂熱：Facebook 創造了跨時代的網頁框架！從今天起所有東西都該用 React.js 來寫！
第四步： 等等，這東西工程浩大，短期之內卻沒有什麼回收！
第五步： React 對於有很多即時通知的單頁應用很棒，但是用在簡單的網頁應用上卻不一定會獲得回報。
範例二：DHH 說的「測試驅動開發已死」
第一步： David Heinemeier Hansson（DHH，創造 Ruby on Rails 的人）發現在 Ruby on Rails 上做測試驅動開發有所困難。因此做了一個務實的決定－不先寫測試。
第二步： DHH 的部落格文章跟演講開始了一窩蜂。關鍵字： 測試驅動已死。
第三步： 大大都這樣說了，我們就別寫測試了。反正我們本來就不會寫，現在我們也不假裝會寫了。我們終於誠實面對自己了。
第四步： 等等！越來越多東西爆炸了。我們寫出一堆蟲。
第五步： Kent Beck：「測試驅動沒有所謂的活著或是已死，它是個取捨：要看被改 API 的風險有多高，參與的程式設計師的能力還有既有的設計為何」
範例三：Microservices
第一步 Monolithic application 難以擴展。現在有個做法是把它拆解成很多小服務。這樣每秒能處理的需求量可以更方便做擴展 ，跨團隊的擴展也更容易做到。
第二步 關鍵字：可擴展性（Scalability）、低耦合（Loose coupling）、Monolith。
第三步 我們把所有東西都成寫成服務吧！我們的程式一團亂都是因為我們用的是 Monolith architecture！我們必須把所有東西都改寫成 Microservice 。
第四步 挫賽！現在開發變得超慢的，部署也變困難了，然後追 bug 要橫跨多個系統。
第五步 Microservices 需要有經驗的團隊還有在正確的時間點投入才有可能在系統與團隊擴展時有所回報。當你在遇到真正的擴展問題前用就是過度投資。Microservices 往往是拆解出來的而非直接寫成，你要這麼大才能用 Microservices。
範例四：NoSQL
第一步： SQL 資料庫在處理高負載跟非結構式資料（Unstructured data）時會遇到困難。世界各地的團隊開始開發新一代的資料庫系統。
第二步： 關鍵字：擴展性、大數據、高效率
第三步： 我們的資料庫跑得慢又不夠大，我們要 NoSQL！
第四步： 我們需要 join 操作？這做不到。簡單的傳統 SQL 操作變得越來越困難。開發越來越慢而問題本身還是沒有解決。
第五步： NoSQL 是為了解決非常特定問題的答案（極大量、非結構式、或是高負載）。SQL 經過良好的調校還是可以處理高負載跟大量資料。到了 2016，應該使用 NoSQL 的情境還是少見。
範例五：Elixir 與 Phoenix（或是任何一對你最愛的語言／框架組合）
第一步： Ruby on Rails 之類的框架沒有辦法好好處理需要高效能、分散式、還有 WebSocket 的需求。
第二步： 關鍵字：擴展性、高效能、分散式、容錯（Fault-tolerant）
第三步： 我的天，我們的應用程式超慢然後對話功能竟然不能擴展！
第四步： 哇，函數式程式設計跟分散式程式設計超難學的。我們進展緩慢。
第五步： Elixir 跟 Phoenix 是好東西，但是需要大量的時間才能學好。如果你真的需要特別高效率的應用，長期來說是有正向投資報酬的。
範例多的是：
在電腦工程有許多領域一窩蜂的情況時常發生，JavaScript 的世界裡天天都有新框架。Node.js（關鍵字：事件驅動開發）、Reactive programming、Meteor.js（關鍵字：Shared state）、前端 MVC、React.js，應有盡有。軟體工程領域裡我們有 Domain driven development、Hexagon、DCI。你最喜歡的一窩蜂現象是什麼？
比較好的作法
如果我們不能盡信網路上的說法還有別人們的意見，那我們該怎麼決策呢？以下是一些比較好的實踐：
在用之前先研究測試
- 快速測試（Spikes）－依靠自己的經驗而非別人寫的文章。在你下決策之前，花一到兩天用新技術建造一個新功能的原型。讓團隊一起來分析利與弊。有時候你會想要把團隊拆成幾個小組，各自選定一個在同領域不同的新技術製作原型，然後來比較優劣。
- 黑客松是一個讓團隊熟悉如何取捨各種不同技術的好環境。花個一兩天讓團隊成員去嘗試各種看起來很誘人的新技術，可以讓他們學會如何靠經驗下聰明的決策。
什麼時候下手？
- 原則上是投資報酬率很高的時候就下手。很多技術都是為了要解決特定問題而產生的。你有一樣的問題嗎？這個問題很嚴重嗎？用了會省下很多時間嗎？花在重寫跟學習的成本能回收嗎？如果起步的開發速度會剩下一半可以接受嗎？如果慢到四分之一呢？這樣還值得嗎？
- 好團隊可以讓你做更多嘗試－有些團隊就是能比其他團隊更快交付，當事情一成不變的時候他們也會更快厭倦。這種團隊能更頻繁地試用新技術，但不能因為這樣就略過黑客松跟快速測試這兩個技巧。反而言之，如果團隊連正常交付都有問題了，那就要謹慎為之。
雇用對的人
- 有扎實技術背景的人是你的好朋友－知道越多範式（Paradigms）、對程式理論（例如演算法、平行處理）越熟悉、或是有好的工程素養的人通常比較不會跟風。
- 經驗－通常越年輕的開發者越容易一窩蜂。見過不同技術來來去去甚至自己被一窩蜂咬過的人做決策會比較平衡。
