【編者按】軟體質量的好壞與很多因素有關，例如開發者的投入水平，採取測試手段的標準，都有可能成為低質量的誘因。
原文連結：https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software
未經允許，禁止轉載！
作者 | George 譯者 | 明明如月
責編 | 夏萌
任何工具的使用情況、團隊溝通的質量、開發者的投入水平以及採取的測試手段都可能成為低質量軟體的誘因。
我認為，導致低質量軟體的根源是：虛構問題。
許多複雜或有缺陷的軟體並不是因為它們的設計過於複雜或功能不平衡，而是因為它們試圖處理一些超出其最初預定目標的任務。
假如你是一個播客主播，想創建一個專屬的網站。你想要在該網站上推廣產品，直接獲取廣告收入，無需經過第三方，而且，你可以提供播客、視訊和部落格內容給觀眾。
你的小型網頁應用可能包括以下需求：
在北美地區能快速載入，提供實時播客播放和下載
在啟動後的前 15 分鐘內，對 99.99% 的使用者保持穩定運行，理想情況下，不會崩潰或假死
能高效地集成 Google Adwords，如果有足夠的時間，可以考慮集成其他第三方廣告商
可以動態連結到你在 Zazzle 商店中的最新產品，並根據使用者的購買歷史進行推薦
能集成 Facebook 的直播系統，如果可能的話，最好能設計一個獨立於 Facebook 的直播系統
你把這些需求交給了一支外包團隊，並進行了討論。剛開始，似乎所有人都在同一個頻道上。然而，當他們兩個月後交付了最小可行產品，你感到憤怒。你覺得你花了 15,000 美元做了一堆無用的垃圾，你想要退款。
你第一次打開這個網站螢幕就卡住了。當你詢問開發團隊如何選擇在網站上運行的廣告類型時，你被引導到一個醜陋且難以理解的自定義使用者界面（UI）。你在 Zazzle 商店的商品連結有一半無法使用，或者缺少圖片，而且Facebook直播非常卡頓！
對此，開發團隊也表示很困惑，他們認為你的憤怒表示不解，因為他們為此付出了大量的努力。
他們全力投入到了這個應用的開發中，他們甚至創造了一些令人驚歎的功能：
設計了一個先進的推薦系統
設計了一個可以實時生成所有流媒體文字轉錄的演算法
設計了能在全球任何地方在 200 毫秒內載入你網站首頁的功能
為了避免你過度依賴 Facebook 直播，設計了一套全新的流媒體協議和客戶端
可以讓你輕鬆集成超過 20 個廣告平臺的服務
你期待的是一個核心功能完備的產品，如果可能，再加入一些額外的功能。但開發團隊理解的是一個完全不同的需求。他們聽到的是一系列興奮的挑戰……以及一些他們不太關注的基礎功能。
更糟的是，你並沒有直接與開發團隊的成員進行溝通，而是通過一個銷售員進行溝通，像玩傳話遊戲一樣，然後銷售員與一些中級管理人員開會，然後寫出一套業務規則給項目經理，項目經理再撰寫一些技術規則給團隊負責人或架構師，然後，他開始和他的團隊設計產品，在過程中，每個人都在產品上添加了他們自己的理解和特性。
這是一種應對機制
通常，虛構問題比實際存在的問題更有趣。天才喜歡玩電子競技遊戲，構建並解決數學問題，甚至會通過編寫書籍來回答關於人類狀況這類抽象問題，而這些通常是免費的。然而，當你找一位普通的程式設計師開發一個簡單的 Android 應用，他就可能收取費用。這不是因為普通程式設計師比天才更稀有，而是因為前者的工作往往更有趣，而後者的工作可能相對乏味。
大部分的程式設計師都希望他們的工作能既帶來收益，又能給他們帶來樂趣。當然，”樂趣”的定義因人而異，但對很多工程師來說，它主要體現在解決那些富有挑戰性且有趣的問題上。
如果你給一個智力出眾的人分配過多不能自動化的、枯燥無味的任務，你可能會讓他感到抓狂。然而，經過數十億年的演化，人類的大腦已經相當擅長在保持理智思考。就如同那些在童年時期經歷困難或者虐待的人會在奇幻小說中尋找現實的解脫，那些從事企業應用開發或者網頁開發的人也能通過解決虛構的問題找到他們自我釋放的方式。
軟體工程師虛構問題的數量，是由他們的創新思維（即他們能想出多少虛構問題）與他們實際工作中存在的複雜問題的數量共同決定的。
值得一提的是，這個問題並不僅僅侷限於開發人員。無論是管理層、銷售團隊、人力資源、技術支持、法務部門，甚至會計部門，他們都有自己特別的方式來創造虛構的問題。他們試圖過於干預決策，哪怕他們在會議上的出席只是形式，或者他們甚至並沒有被要求參加。他們會過於聚焦於與自身職責相關的瑣碎問題，或者聘請遠超實際需求的團隊規模，只是為了證明自己的重要性。
面對愚蠢的問題，聰明的人總能找到解決的辦法。
然而，虛構問題的產生並不只是因為開發人員過於閒散，而且還有可能源於溝通鏈路過長。
我在開始做自由職業者的時候，因為希望接觸更多的工作機會，所以對選擇的客戶或者他們的要求並不會過於挑剔。常常會遇到一種情況，就是為了討論一些內部的最小可行產品的細節，需要和客戶通過上百封郵件進行交流。我也經歷過一週之內需求不斷變動的情況。甚至我也曾有客戶問我：「這個項目可以進行代幣融資（ICO）嗎？」或者 「我們能否在這個項目中加入一些 AI 技術？」
誠然，大部分的客戶要比這些情況好一些，但他們往往缺乏清晰表達自身需求的能力。這其實並不是問題，因為作為「計算機專業人員」，我的工作就是根據他們的使用場景來幫他們分析他們需要什麼，不需要什麼。但當你和客戶之間存在若干層次的隔閡時，確定需求就變得極其困難。
需求的變動可能源於對目標的誤解，或者源於人們試圖對上述的枯燥狀況作出反應。
大多數公司都喜歡擁讓銷售人員去推銷產品，談價格，並說明這個價格可以得到哪些功能。也會有一些善於人際交往的人與客戶更深入地討論需求細節，他們其實也算是銷售人員，只是他的職位並不是銷售。然後，就是內部的傳話鏈，包括各級管理人員，以及技術團隊內部的層級結構。
當一份客戶需求清單經過如此多人手後，某些事情也無可避免地會在傳話過程中丟失。有時，需求的變動源於原始需求沒有意義，或者需求需要被重新定義。銷售人員可能已經告訴客戶，「只需額外支付 39999，我們就可以在區塊鏈上實現這個。」 然而這就讓後續接觸需求的每個人都在思考，「在區塊鏈上實現這個」 到底是什麼意思。
更常見的情況是，需求的變動可能源於人們對意圖的誤解，或者人們試圖對前述的無聊狀況作出反應，試圖讓自己的工作或者他的團隊的工作變得更有趣，更吸引眼球。
在這種情況下，最初的需求——真正需要解決的問題——被淹沒了。真正需要解決的問題被虛構的問題和空白所取代，你會發現很多人願意用他們自己的虛構問題來填補這些空白。對他們來說，他們面對的問題實在過於枯燥，而填補這些空白，則成為了一種解決手段。
過度複雜化與自然選擇
虛構問題的存在並非毫無緣由，而是深層次的機制在起作用：這些問題可能推動了一個團隊或公司的進步，甚至成為其運轉的關鍵部分。
正如 Nassim Nicholas Taleb 所說：「那些被培養、選拔和獎賞出來的人，用以解決複雜問題，往往不會去積極尋找簡單的解決方案。」
你有沒有聽過這樣一件事，只有三個網路工程師就從零開始開發出一款無瑕疵的銀行軟體，運用了功能性設計方法論和記憶體安全語言，並且成功地使大型銀行遷移到他們精心構建的完美基礎設施上？
可能沒有，因為這樣的事並不存在。但實際上，卻有一大群開發者，他們可能連「回滾」這樣的基本概念都難以理解，卻在銀行業編寫著重要的軟體。
儲存和傳輸數字的技術要求並不高。索引整個網路的內容，並在一秒內為自然語言查詢提供相關的結果，這才是真正的技術挑戰。然而，只有極少數的天才選擇去解決這個問題。
銀行生態系統已經熟練地維護了自身的收入階層。領導層可能像寄生蟲一樣侵蝕社會，但這只是這些機構的一種表現。
並不是說大部分在銀行工作的普通員工都有惡意。相反，他們大多是友好的普通人，他們為了生活，為了家庭，辛勤工作，努力提供食物、住房和教育。但是，他們的主要動力並不是去改善銀行軟體，而是保住自己的飯碗。在今天的經濟環境中，失業的影響對一些人來說太過沉重。在銀行業，過於直言不諱或者過於積極進取，可能會讓人陷入紀律審查的困境。
因此，銀行系統的保持不變並非是因為它們高效，而是因為慣性在起作用。這種慣性表現為處理虛構問題的形式，以避免解決真正的問題，因為一旦真正的問題被揭露，可能會威脅到他人的飯碗。關注真正的問題反而可能導致被解僱，甚至在一些情況下，比如在高盛，可能會引發一系列的嚴重後果，甚至導致引起高度關注的自殺事件。
Upton Sinclair 曾說過：「當一個人的收入依賴於他對某事的無知，你很難讓他理解那件事。」
通常情況下，公司的最高領導層（C-suite）對於高管將 90% 的時間花費在「客戶會議」上並不會特別關注，儘管這些「客戶會議」可能在度假勝地舉行，且包含的「其他費用」可能高達數百萬美元。同樣地，次一級的高級管理層也會對上層管理人員可能存在的行為不檢的情況視而不見。他們也會忽視中層管理人員對《華爾街之狼》式夢想的熱衷，即使這可能涉及購買一些奇特的辦公設備，或是僱傭過多的秘書和實習生。
當面對基層管理人員對權力過度集中的幻想，中層管理人員往往也會選擇忽視。他們更傾向於關注那些喜歡進行「如何改進我們的敏捷方法論」 PPT 彙報的人，而不是那些實際上能夠削減成本的基層經理。
團隊領導似乎沒有注意到他們的上司只是偶爾在辦公室露面，根本不會正確使用 Excel。而基層經理也忽視了那些團隊領導和架構師，他們熱衷於談論「 如何用JRPC、Hibernate 和 Spring 進行微服務改造」，而忽略了實際上應該最佳化那些低效的 MySQL 查詢。開發人員似乎並沒有意識到他們的領導除了畫 DOT 圖表之外，其實並不真正編寫任何程式碼。而團隊領導也並沒意識到開發人員頻繁地換用新的 JavaScript 框架，頻繁地修改 UI，而不是通過 EXPLAIN 來解決資料庫查詢緩慢的問題。
這是一個惡性循環，各層級都在忙於處理虛構的問題，從 CEO 忙於追逐財富，卻忽視處理家庭問題，到 UX 實習生為了重新設計一個「提交按鈕」 忙得焦頭爛額，他們的密碼甚至以明文形式傳輸（並將其作為認證cookie的一部分）。
然而，每個人都繼續解決虛構的問題，因為一旦他們停止創造和解決這些虛構的問題，他們就需要開始面對真正的問題。一旦他們開始解決真正需要解決的問題，他們可能會發現整個系統瀕臨崩潰。他們可能會發現，儘管公司已經在五年前就將伺服器就遷移到亞馬遜 Web 服務 （AWS），但是 Debra 仍舊每天守在角落裡，盯著內部伺服器的運行圖表已經長達 10 年之久。他們可能會突然意識到，自己的有 99% 的工作只是為維持他人的職位。這是一種難以接受的現實，我敢說，對大多數人來說都是無法接受的。因此，大多數人選擇通過處理虛構的問題來避開這些真正的問題，以逃避這個令人難以接受的現實。
本文引起了很多網友對低質量軟體原因的大討論。
有些網友認為，軟體行業的激勵系統才是問題的根源。軟體行業的激勵機制過於側重於傳統的標準和量化指標，而忽視了對於解決真正問題的思考和創新。例如，設計師得到晉升的標準可能是創新和巧妙的設計，而不是堅持傳統設計。工程師的晉升機會可能與他們重寫程式碼、提出更多解決方案（甚至多於存在的問題）有關，而不是保持程式碼庫不過度增長。產品經理可能被獎勵的是他們提出的新功能，而不是使產品更穩定和易用。這種情況下，努力和付出的方向可能受到了偏差，因為激勵機制更關注表面上的成果和創新，而忽視了解決實際問題和提高軟體質量的重要性。這可能導致軟體行業過度追求數量而不是質量，以及過度追求新功能而忽視穩定性和使用者體驗。軟體行業需要對激勵系統進行深思熟慮，更加關注努力和付出的方向，確保努力和創新的目標是朝著解決實際問題和提升軟體質量的方向發展。
也有網友認為，公司冗員是降低軟體質量的原因之一。他認為公司僱傭的人太多了，經理們為了晉升自己需要更多的下屬，而他們希望管理更多的經理來繼續晉升。結果是我們組建了龐大的團隊來開發原本只需要少數工程師就能完成的產品。這種情況下，我們在龐大的團隊中，將工作分割得非常細緻，甚至為了創造新的領域而發明，結果卻經常破壞了產品。此外，人員過多也導致工作變慢，協調的成本很高，並且當產品被分割成小部分並不斷發展時，我們會失去整體上下文的理解。
還有網友認為，「面向KPI程式設計」是導致軟體質量下降的重要原因。這意味著人們更關注實現特定的關鍵績效指標（KPI），而不是關注如何提高公司的盈利能力。這種現象在一些大型科技公司中尤為明顯。員工可能更關注如何實現自己的晉升目標，而不是將公司的利益置於首位。這種「晉升至上」的價值觀可能導致員工更關注對個人有利的行為，而忽視了為公司創造真正價值的努力。然而，這種偏重於個人晉升的傾向可能會對軟體質量產生負面影響。因為員工可能更傾向於追求短期的成果，而忽視了長期穩定性、可維護性和使用者體驗等對軟體質量至關重要的方面。
參考連結：https://news.ycombinator.com/item?id=36380711
