【编者按】软件质量的好坏与很多因素有关，例如开发者的投入水平，采取测试手段的标准，都有可能成为低质量的诱因。
原文链接：https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software
未经允许，禁止转载！
作者 | George 译者 | 明明如月
责编 | 夏萌
出品 | CSDN（ID：CSDNnews）
任何工具的使用情况、团队沟通的质量、开发者的投入水平以及采取的测试手段都可能成为低质量软件的诱因。
我认为，导致低质量软件的根源是：虚构问题。
许多复杂或有缺陷的软件并不是因为它们的设计过于复杂或功能不平衡，而是因为它们试图处理一些超出其最初预定目标的任务。
假如你是一个播客主播，想创建一个专属的网站。你想要在该网站上推广产品，直接获取广告收入，无需经过第三方，而且，你可以提供播客、视频和博客内容给观众。
你的小型网页应用可能包括以下需求：
-
在北美地区能快速加载，提供实时播客播放和下载
-
在启动后的前 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
本文文字及图片出自 CSDN
你的反应是：