📰 1. Why Software Factories Fail (or: harness engineering is not enough)

🔗 原文連結

TITLE: 為什麼軟體工廠會失敗（或者：只靠工程管理是不夠的）

原文摘要

這篇技術報導（原文來自國外技術社群）點出一個殘酷現實：許多公司砸錢導入「軟體工廠」模式——標準化工具鏈、嚴格的CI/CD流程、統一的程式碼規範——卻依然產出爛產品、團隊士氣低落。作者直接打臉「只要把工程管好就能量產軟體」的幻想，指出「harness engineering is not enough」（單靠工程管理遠遠不夠）。真正的瓶頸往往卡在人才、溝通、以及對商業目標的理解上，而不是少了哪個自動化工具。

我的觀點

我完全認同這篇的核心論點：軟體工廠的失敗，根本不是技術問題，而是「把人當成螺絲釘」的思維在作祟。 很多管理者誤以為寫程式跟組裝iPhone一樣，把任務切碎、分配、驗收就能複製成功。但軟體開發本質上是「創造」，不是「製造」——需求會變、設計會錯、技術會老，你不可能用一條固定產線來應付動態的市場。更常見的是，為了強推標準化，工程師被迫在僵化的框架裡繞遠路，反而拖慢速度。講白了，工廠模式是工業時代的遺毒，用在資訊時代只會逼走強者、留下聽話的平庸之輩。

延伸思考

這件事讓我想起微軟、Google內部也踩過類似的坑。幾年前微軟大力推「軟體工廠」概念（還出了Visual Studio套件），結果很多團隊抱怨樣版程式碼比業務邏輯還肥。後來Google提倡「20%時間」跟小團隊自治，反而更成功。真正該強化的不是流程，而是「反饋速度」跟「容錯文化」。 延伸來說，現在AI輔助開發越來越強，如果還死守工廠思維——叫AI照著模板猛產程式碼——那你只是在加速製造垃圾。未來的競爭力是「判斷力」跟「設計能力」，不是產線效率。

---

📝 編輯說：: 這篇文章在Hacker News上引發了大規模的工程師共鳴，筆者認為最打動人的是那句「管理流程像鎧甲，穿太重會淹死創意」。

---

📰 2. BlackRock、Strategy 和 Coinbase 支持 1500 萬美元比特幣安全聯盟

🔗 原文連結

原文摘要

這則消息來自 Yahoo Finance 的報導：資產管理巨頭 BlackRock、軟體公司 Strategy（就是那個狂買比特幣的 MicroStrategy 改名後的新公司）以及交易所 Coinbase，共同出資 1500 萬美元，成立一個專注於比特幣網路安全的產業聯盟。聯盟的具體名稱尚未公布，但目標很明確——協調資源、開發工具、分享威脅情報，來抵禦針對比特幣協議的攻擊，特別是 51% 攻擊、節點漏洞或錢包層面的威脅。這筆錢不算天文數字，但三家重量級玩家的背書，讓這個聯盟的象徵意義遠超金額本身。

我的觀點

1500 萬美元大概只夠 BlackRock 管理費的零頭，但這個動作暴露了傳統金融巨頭對加密貨幣基礎設施「安全焦慮」的真實程度。過去機構只敢碰 ETF 或託管服務，現在願意掏錢修馬路，代表他們開始把比特幣當作長期持有的資產類別，而不是投機工具。比較有趣的是 Strategy 的參與——這家公司本身就是比特幣最大的公開持有者，它的安全需求比其他人都迫切。Coinbase 則一直想從交易所轉型成基礎設施提供者。三方的利益高度交織：BlackRock 要的是客戶資產不出事，Strategy 要保護自家金庫，Coinbase 要鞏固託管業務的專業形象。這個聯盟本質上是「既得利益者」的聯合防守機制，對散戶來說反而是好事——至少有人願意花錢堵漏洞。

延伸思考

比特幣網路已經運作十幾年沒被真正攻破過，但風險從來不在協議本身，而在周邊生態——交易所、節點軟體、錢包私鑰管理。這次聯盟如果能產出開源的安全工具或標準，對整個產業的成熟度是正向催化。不過我比較在意的是「聯盟治理」：BlackRock 會不會藉此影響比特幣的開發方向？例如推動某些政策來符合監管要求？這就觸及到比特幣去中心化精神與機構力量之間的平衡點。另外，1500 萬美元在安全領域其實不太夠用——一個優秀的資安團隊年薪可能就要吃掉一半。希望他們不是只辦幾場峰會就交差，而是真能產出實質的程式碼或威脅情報共享平台。

📝 編輯說：:這篇文章在 Yahoo Finance 引發不少討論，筆者認為最有價值的觀點是點出「機構抱團修基礎設施」背後其實是資產託管焦慮，而非純粹的公益心態。

---

📰 3. Ask HN: Is there a website that tracks excessive writes to SSDs in OS/app betas?

🔗 原文連結

TITLE:請教HN：有網站追蹤OS/App測試版過度寫入SSD嗎？

原文摘要

Hacker News上網友amichail拋出一個實用的問題：「有沒有像資料庫一樣的網站，專門記錄OS或應用程式測試版對SSD的過度寫入？」 他認為，如果這類資訊公開且統整，使用者就能根據自己能接受的「SSD磨損」程度，決定要不要安裝某個測試版軟體。同時，開發者為了減少負評，也會更謹慎地控制測試版的日誌寫入量。

底下的討論很精彩：

• 有開發者分享自己架了 Grafana + Prometheus 監控工作站，並設定了「長時間密集寫入」的警報，等於自己打造專屬的SSD健康儀表板。
• 另一位網友CharlesW表示，用 DriveDx 看他的2022年Mac Studio，SSD壽命還有94%，並提到2021年M1 Mac的「寫入恐慌」後來被證實是誤報。
• 提問者追問：「但如果我打算讓筆電撐10年呢？」於是引發了一串關於可更換零件（如Framework筆電）、AppleCare訂閱、以及焊死SSD的日常討論。

我的觀點：你每天默默「燒」掉多少SSD壽命？

你可能遇過這種情況：新買的Windows筆電裝了某個開發者預覽版，結果一個下午硬碟燈狂閃，CrystalDiskInfo顯示「健康度」掉了好幾%。或不自覺地上網查「Chrome為什麼一直寫入磁碟」。實際上，SSD壽命多數人根本無感，因為一般使用下，寫入量遠低於標稱的TBW。但測試版軟體（尤其是開發中尚有除錯記錄大噴發的版本）就像一個無聲的「寫入炸彈」。

我同意原PO的核心訴求：資訊透明化。目前缺乏一個眾包平台來收集各測試版軟體的寫入量數據（例如每小時寫入GB數）。如果社群能自發建立這樣的清單，對開發者也是正向壓力——他們會更注意日誌層級、快取機制，甚至提早修掉「忘記關閉除錯輸出」的低級錯誤。當然，開發者也有苦衷：沒有詳細日誌，Bug就很難抓。

但站在使用者角度，我認為與其單純封鎖測試版（會錯失新功能），不如自己建立「SSD監控儀表板」。像文中網友提到的Grafana方案，或是簡單的 iotop 定時記錄，搭配生命週期管理工具的Alert，就能在SSD被「寫到哭」之前收到通知。

延伸思考：焊死的SSD vs 可更換的未來

這則討論也凸顯了一個更大的趨勢：現代筆電（尤其是Mac）的SSD多為焊死設計，更換需要整塊主機板，成本極高。這讓SSD的寫入壽命從「可更換的消耗品」變成「與主機綁定的關鍵壽命指標」。

另一方面，Framework等可模組化筆電正努力打破這個限制，但主流市場反應仍偏冷淡。對一般使用者而言，或許更務實的作法是：

• 將SSD監控納入常規維護（像檢查電池循環次數一樣簡單）
• 選擇有AppleCare等延長保固，把維修風險轉嫁
• 在安裝任何測試版軟體前，先手動設定系統日誌的寫入緩衝（如Logging的輪替策略）

最後，如果你真的擔心SSD短命，最省事的做法是：把測試環境移到虛擬機或雲端VM，寫壞了也不痛不癢。這才是終極解法。

📝 編輯說：:這篇在Hacker News上引發了超過19則留言，不少工程師分享自己用Prometheus + Grafana或自訂腳本來監控SSD寫入的經驗，也帶出「可更換零件 vs 焊死設計」的永續性討論。

---

📚 本日原文來源

• Why Software Factories Fail (or: harness engineering is not enough)
• BlackRock、Strategy 和 Coinbase 支持 1500 萬美元比特幣安全聯盟
• Ask HN: Is there a website that tracks excessive writes to SSDs in OS/app betas?

---

本文由JK Space News彙整，不代表任何投資建議。