Venkat Subramaniam — Broomfield, Colorado, USA

速度的假象#

軟體專案經理承受著快速交付的巨大壓力。但「快」真的是我們想要的嗎？

想像團隊裡有兩位程式設計師：Bernie 和 Rob。兩人能力相當、領域知識相同，語言技能也不相上下。觀察開發過程，Bernie 完成功能的速度明顯快於 Rob。

• Bernie 的風格：專注於快速完成程式碼，一路向前衝
• Rob 的風格：寫完程式後進行重構（refactoring），改善變數與函式命名，拆分成小型模組，並撰寫**測試（tests）**確認每個部分正確運作

若只看完成速度，Bernie 看起來是更好的選擇——但幾週後，情況開始翻轉。

地鼠遊戲（Whack-A-Mole）#

客戶試用後提出修改需求。Rob 負責的功能修改順利，客戶滿意。但 Bernie 負責的功能卻出現問題：

• 新功能加進去了，但原本正常的功能壞了
• 修好這個，另一個又壞了
• 缺陷如地鼠般此起彼伏，永無止境

注意： 這正是「打地鼠（Whack-A-Mole）」開發模式——修一個 bug，另一個隨機冒出來。這種模式令人沮喪、難以預測，嚴重拖累產品開發進度。

可持續進度的真正意義#

Rob 看似較慢，實際上卻創造了更高品質的程式碼：

• 良好的程式結構讓後續修改快速且可靠
• 測試提供即時回饋，確認新變更不會破壞其他地方
• Bernie 是在衝刺，但方向錯了；Rob 的步伐才是真正可持續的

重點： 評估功能開發時間時，不能只算「第一次寫完」的時間。必須把後續的增強、修復、改善一起計入。撰寫高品質程式碼和測試雖是短期成本，卻能帶來長期收益。

該問自己的問題#

你要的是速度（speed），還是可持續的進度（sustainable progress）？

技巧： 鼓勵團隊在開發時同步撰寫測試，並定期進行重構。這不是在浪費時間，而是在投資未來的開發速度。

附註：重構（Refactoring） — 在不改變外部行為的前提下，改善程式碼內部結構的過程。目的是讓程式碼更易於維護，並降低未來修改的難度。