作為程式開發者，每次聽到「加個 flag 就好」或者「開個變數存起來」這種話總是會心頭一驚。理由也很正常，就是像這樣子的 workaround 並沒有真正解決問題，只是徒留技術債，以後怎麼爆炸的都不知道。 workaround 聽起來真的是十惡不赦，不是嗎？ 可凡存在必有道理，不如來聊聊 workaround 的好處在哪(？) Workaround — 權衡下的妥協 先來看看哪些情況下我們會以 workaround 作為解法 突發事件下的緊急修復：當系統發生意外（比如重大錯誤或者漏洞），此時為避免事態擴大，緊急下 workaround 來修復是個不錯的做法。 第三方套件造成的問題：引入第三方套件的目的就是要「使用」而非「重製」，在這種情況下遇到問題或者不符使用時下些 workaround 繞開或補丁可能就是個常見做法。 歷史代碼的封裝：陳年舊程式碼往往無法保證其正確性，復用時透過 workaround 隱藏錯誤可能是必要的。

高三指考前跟畢業之間隔了半個月左右，那段時間就回到家裡讀書。 附近的圖書館常常都是坐滿了人，沒位子時就會跑到當時新開的文化大樓樓上的圖書室。當時知道的人不多，後來就預設去那了。不知道為什麼那短短半個多月的記憶卻很清晰。 早上吃完早餐剛好經過文化大樓，一時興起就走上去看看逛逛。 時隔二十年再訪，發現蕭瑟了許多。不只圖書室搬空不見了，連地上都沒有打掃乾淨。不太確定發生了什麼，突然有點落寞。

幾年前有次去談案子，業主想要透過整合資訊工具來替自己的產業做些商業模式的新嘗試。但隨著討論的逐漸深入，默默覺得有些違和感，總覺得有一層窗戶紙沒有捅破。 意識到是業主對於系統開發後的維護認知有點奇怪，點破之後聽到一句有趣的話： 「為什麼要維護？有 bug 你們就要負責啊，你們怎麼可以給我們有 bug 的東西！」 一瞬間我也是愣了一下，還差點被說服（？）。仔細想軟體維護好像還真的是不太好理解。 系統正常運作是結果而非手段 軟體維護的目的其實很單純 — 讓系統能夠正常的運作。 有句話說「幸福的家庭都是相似的 不幸的家庭各有各的不幸」，放到軟體上也是一樣。程式有 bug？流量超乎預期？雲端系統更新？版本控制錯誤？每個點都可能局部甚至全局造成系統失效。 而所謂的「正常運作」其實更是結果。站在終點規劃從起點該如何走來往往會是顧了這個漏了那個。 那該怎辦才好？ 與其把視角放在具體的每一個任務上，不如去思考最基本的出發點 — 也就是風險的轉移及專業承擔。

近年來 NFT（非同質化代幣）的出現顛覆了數位資產領域，帶來了重大的生態改變。其去中心化和可二級交易的特性為數位藝術、音樂、遊戲等領域開啟了全新的玩法和價值發現。 然而，如果我們將視角放得更廣，我們可以發現我們的世界實際上由虛擬和實體兩個部分組成。NFT已經在虛擬世界中證明了自己的價值，但如果將NFT應用於現實世界，又會有哪些可能性呢？ 元宇宙可能是未來，但線下生活卻會永存 在過去幾年中，元宇宙引起了廣泛的關注，許多概念也納入了其中，無論是人工智慧還是虛擬實境都在其中找到了討論的空間。總的來說，透過資訊技術突破物質限制、擴大創造力並重新建構既有關係，這很可能成為數位時代的未來形態。 朝著虛擬世界發展似乎已成為一個不可逆轉的趨勢。 然而這並不代表一切的全貌。畢竟我們仍然生活在現實的物質世界中，許多我們習以為常的體驗很難被取代（或者說不應該被取代）。此外，在線下世界中已經孕育出了許多價值。因此，一個完整的未來世界應該是虛實兩個領域相互輝映、融合的。

做了這麼久的軟體開發 花很多時間在溝通同一個概念 「不是不給你改，是真的不適合改」 軟體本來就沒有不能改的，單純要看值不值得 所謂的值不值得有很多角度 從最簡單的合約關係到資源問題 但更重要的其實是風險引入跟交接 系統是一步一步搭建上來的 每個部分都有設計假設在後面 牽一髮本就會動全身 想要局部修改而不影響整體不太可能 真的做到完全隔離那要賠上的可能是更多資源及效能 有時候很想跟甲方說其實乙方是真的負不了責 乙方能負責的只有自己寫的程式跟設計 但這些程式跟設計並無法簡單對等到商業利益及多變的環境 需求變更一直都是常態 期待用很多討論跟文件去鎖住往往是不實際的 說到底要相信人力有時而窮 真實世界總是有很多的不確定性 最後 為什麼總是都要談成本？ 一方面除了大家都不能靠光合作用存活之外 這也是少數能讓對方都認真看待事情的方式 積極一點來看 成本的討論反映的可能只是立場而非限制 當然背後更深遠的是信任問題 這個就沒辦法討論也只能靠日積月累了

AutoGPT 這幾天蠻紅的 對工程師來說不知道是喜從天降還是禍從天降（？ 身在資訊業十幾年，參與過各式專案跟產品 每次遇到困難時總會想起「人月神話」這本書 人月神話揭示了軟體開發的一些特性及悲劇來源 當中「沒有銀彈：軟體工程的本質性與附屬性工作」這篇文章更是精彩 (No Silver Bullet — Essence and Accidents of Software Engineering) 裡頭完整的討論了軟體開發的附屬性及本質性問題 前者比較好處理，工具的發展就能很好的突破困境（比如高階語言及 IDE 的發展） 但後者就麻煩多了，軟體要面對的複雜性及易變性往往難以被規範 這也導致被過往被寄與厚望的物件導向等技巧實際上不容易有效的大規模鋪開 AI 不知道會不會是這個問題的解方？ 真正複雜的是人，但最了解人的在未來也未必是人了 最後 人月神話作者 Frederick Phillips 在 2022/11/17 過世了 而 chatGPT 卻是在 2022/11/30 發布的 或許對程式設計師來說 2022 的 11 月就是軟體開發的歷史奇點

軟體開發是結合領域知識、工程方法及成本控制等多面向的複雜任務，尤其在這個技術發展越來越快、用戶需求越來越細緻的時代，複雜度往往遠超想像。 而對一個新商業模式或數位轉型來說，驗證可行性及解決既有的痛點難度本就不低，如果還得再加上對於資訊技術的掌握度要求就更容易招致失敗。在這種情況下，尋求外包、找專業的支援就是個很理性的選擇。 但外包合作有那麼簡單嗎？且不論夥伴選擇及溝通本身就是學問(參考如何讓你的系統設計能真正解決問題)，有時候連合約怎樣落都是個問題。 本篇文章稍微分享一下過往在合約來回時常碰到的問題及調整方向。 困難之處：非標準品本就容易雞同鴨講 軟體開發易生糾紛之處主要來自於標的物不明確，這也連帶使成本計算變得困難(參考軟體開發值多少？系統開發怎樣估成本)。 可能會有朋友覺得標的物哪裡不明確了？以電子商務來說，這個我們看的還少嗎，打開 google 搜尋一找一大把。但如果仔細思考，你會發現其實這些電商類似的地方在於體驗及用法，背後的運作邏輯甚至可能換間店就大不相同。

「幫我做的跟 Facebook 一樣單純就好」 「嗯 … ?」 工作緣故蠻常需要給客戶軟體開發的報價，也蠻常在不同場合被問說怎樣衡量開發成本。其實這個問題不容易有個確定算法，在這篇文章稍微分享一下過去思考這個問題的關注點，也期待引出不同的觀點。 姑妄說之姑聽之，這裡只分享原則，不涉及具體數字。 而或許，這些原則也可以延伸到其他虛擬服務(如顧問)的定價上？ 以終為始：軟體開發的標的是什麼？ 先聊聊開發的終點到底是什麼。 首先，軟體是一種協助我們的工具及手段，並不是目的本身。甚至好的系統及軟體往往能調動你的直覺，讓你不容易感受到它的存在。 在評估開發的標的時，切記要把關注點放在軟體系統是否能達成目標。細節會有無限多，過度的枝微末節很有可能兩敗俱傷。 規格存在的目的是對甲乙雙方建立完整的認知圖譜，一旦開始執行偏離是常見的事。就好比戰爭前訂定戰術戰略規劃並不是為了能在戰場上算無遺策，而是為了能在有其他干擾因素時仍能準確瞄準最後目標不走偏。

標題有點拗口，但剛好拿來聊聊一個概念 — 認知的邊界。 FTX 的爆炸 vs. ChatCPT 的強大 FTX 爆炸之後，各種專業的、不專業的，陰謀論、貌似客觀的言論非常多，常常讓人看得雲裡霧裡。 有趣的是正著講反著講都通，比如 8% 高利率看似不合理，但新市場總有新機會嘛。試想一下，如果當初 FTX 沒有爆炸，在這個法幣利率已經可以到快 5 % 的今天大家搞不好會因為 FTX 壓力減輕而增加信心（只需要贏過 3 % 就好 ~）。 ChatGPT 也有類似情況，問世之後激起了各種讚揚及惶恐。最近看/聽了一些非理工科系 KOL 的討論，很直接的感受到滿滿的超譯。誒誒不要戰文組理組，很多人類的發展本就來自超譯，不是有句話說 “Fake It till You Make It” 嗎？ 認知的邊界源自我們的想像跟 … 自以為 這時候就想起以前看到有趣資訊，英國史上最偉大的 100 人是那些呢？