I have a theory that software drives people insane
467 points
• 4 days ago
• Article
Link
软件结合了速度、金钱、复杂性和高度抽象的独特特性，能深刻地影响人的心理。尽管大多数软件产品本质上不过是被美化的电子表格，但构建它们的过程常常会扭曲原本理性的人们的视角。想法与实现之间缺乏天然的摩擦，造成一种危险的氛围，使每一次潜在改动都显得迫在眉睫、具有战略意义且刻不容缓。与实体建筑不同，改动平面图会产生明显可见的成本，而改变软件的代价往往是隐形的，通过动力丧失、上下文切换和架构侵蚀逐渐累积。
这种易改性催生出一种文化：每一个"可以"很快就变成"应该"。软件开发中很少有明确的"完成"定义，团队因此常陷入无休止的迭代。每一个按钮、查询或基础设施组件在理论上都可以改进、优化或扩展。行业巨大的金钱潜力进一步放大了这种倾向，使人们对平凡任务赋予过度的情感重要性：一次按钮重设计不再只是界面调整，而被寄予未来财富或公司成功的希望。
复杂性也被当作一种心理拐杖，为那些构建、辩论和重写繁复系统的人提供了重要感与地位感。在许多情况下，这些系统自我强化，其存在更多是为了支撑构建它们的组织，而不是为了解决实际问题。由此形成一个反馈循环：经理、创始人和工程师们觉得必须不断拉动各种杠杆，把公司本身看作一段永远可变、未完成、需要下一次重构的软件。
对速度的痴迷从根本上排斥耐心。实际上，客户、工程师和企业都需要时间来成熟并找到稳定性。当组织把耐心解读为不作为时，就会用一阵阵发布、转向和重塑去取代它，而这往往掩盖了最初更简单的问题。讽刺的是，经过多年堆叠复杂性和反复转向后，团队常常又建议重建最初那个简单的产品，并确信自己发现了什么深刻洞见。
应对这种系统性疯狂的办法不是为了停滞而放慢脚步，而是要重拾一种比例感。这需要纪律性：认识到并非每一次减速都是危机，并非每一个想法都该上路线图，也并非每一个工具都必须成长为庞大平台。承认多数软件的最终目标不过是成为一个好用的工具，团队就能避免对已在正常运行的事物进行自我毁灭式的反复修补。真正的成功在于，当事情运转良好时学会按兵不动，把实用性置于那无尽而神经质的创新循环之上。
Software possesses a unique combination of speed, money, complexity, and abstraction that can profoundly affect human psychology. While most software products are essentially glorified spreadsheets, the process of building them often warps the perspectives of otherwise rational people. The lack of natural friction between an idea and its implementation creates a dangerous environment where every potential change feels immediate, strategic, and urgent. Unlike physical construction, where modifying a floor plan incurs clear, visible costs, the expense of changing software is often hidden, accumulating through lost momentum, context switching, and architectural erosion.
This ease of modification leads to a culture where every "could" quickly transforms into a "should." Because there is no clear definition of "done" in software development, teams often fall into the trap of endless iteration. Every button, query, or infrastructure component can theoretically be improved, refined, or scaled. This environment is exacerbated by the vast financial potential of the industry, which causes individuals to attach outsized emotional importance to mundane tasks. A button redesign is no longer just a UI change, but something weighted with the hope of future riches or company-wide success.
Complexity is further used as a psychological crutch, providing a sense of importance and status to those who build, debate, and rewrite intricate systems. In many cases, these systems become self-reinforcing, existing primarily to support the organizations that built them rather than to solve actual problems. This creates a feedback loop where managers, founders, and engineers feel the need to constantly pull levers. They view the company itself as a piece of software that is perpetually mutable, unfinished, and in need of the next refactor.
This obsession with velocity is fundamentally hostile to patience. In reality, customers, engineers, and businesses require time to mature and find stability. When organizations interpret patience as inactivity, they replace it with a flurry of shipping, pivoting, and reinventing that often obscures the original, simpler problem. The irony is that after years of layering complexity and changing direction, teams often eventually propose rebuilding the initial, simple product, convinced they have discovered a profound insight.
The solution to this systemic madness is not to move slowly for the sake of stagnation, but to regain a sense of proportion. It requires the discipline to recognize that not every slowdown is a crisis, not every idea belongs on the roadmap, and not every tool needs to become a sprawling platform. By acknowledging that most software's ultimate goal is simply to be a useful tool, teams can avoid the self-destructive impulse to tinker with things that already function. True success lies in the ability to leave things alone when they are working, ultimately prioritizing utility over the endless cycle of neurotic innovation.
197 comments • Comments Link
- 当团队与终端用户隔离，依赖项目经理等中间人传递需求时，软件开发就会脱节且低效。直接与用户接触可以提供关键的一手信息，帮助团队把精力放在那些能解决真实问题并降低摩擦的小改进上。
- 在企业环境中，问"我们到底要解决什么问题？"是一项重要却常被忽视的诊断工具。把问题明确记录下来并培养协作思维，可以减少不必要的摩擦，把注意力集中到核心目标上。
- 单靠原始分析数据来驱动产品决策，通常不如可用性研究有效。数据容易被断章取义以支撑既有偏见，而观察用户在界面上的真实困扰则能提供客观、直接且无法忽视的证据。
- 开发者有时害怕直接面对用户带来的阻力，但这种摩擦恰恰是确保产品有价值的必要反馈。缺乏互动往往意味着工作偏离了用户真实需求，或者开发者被错误的激励驱动。
- 与过去相比，当代软件行业面临更多技术动荡和复杂性。许多臃肿的团队架构关注的是管理依赖关系和频繁变化的技术栈，而不是解决底层领域问题。
- 存在一种常见的产品开发反模式：利益相关者对他们实际上不会亲自使用的假想功能给出低质量的正面反馈。真正的验证需要批判性思维和对实际使用场景的观察，而不是寻求表面的认可。
- 保持克制、抵制构建大而不当的平台或不必要功能的冲动，是一项被低估的工程能力。许多公司因过早追求扩展而受损，失去了对那些提供实际价值、但看起来"枯燥"的核心问题的关注。
- 在 B2B 环境中，臃肿复杂的软件往往比简单实用的替代品更占优势，因为买家更看重持续的服务、功能集或与供应商的关系，而非纯粹的软件效率。
- 行业中看似"疯狂"的现象往往只是典型企业动力的折射：无论领域或产品如何，官僚操控、争功和目标频繁变动都是常态。
- 归根结底，软件是为实现用户目标而存在的工具。当开发者忽视这一点，沉迷于内部复杂性、抽象指标或为了简历而开发时，就偏离了软件应有的实用价值。
讨论凸显了软件作为抽象、可扩展工程与解决真实用户问题之间的根本张力。大家达成的共识是：与终端用户的隔绝——不论由开发者自我造成，还是由管理层强制执行——是低效和挫败感的主要根源。参与者认为，虽然分析数据和项目管理有其用处，但它们常常只是薄弱的决策外壳，忽视用户体验，导致产品过度设计且使用率低下。最成功的做法，是对简洁性保持纪律性的承诺，并愿意直面用户行为的现实，即便这些反馈与内部假设或公司议程相冲突。 • Software development becomes detached and mentally taxing when teams are siloed from actual users, relying on intermediaries like project managers to convey requirements. Engaging directly with users provides vital grounding and helps focus efforts on small, friction-reducing changes that solve real problems.
• Asking "What problem are we trying to solve?" is a critical but often overlooked diagnostic tool in corporate environments. Explicitly documenting the problem and fostering a collaborative, team-based mindset can help reduce unnecessary intensity and focus on core objectives.
• Relying on raw analytics to drive product decisions is often inferior to usability research. Data can be misinterpreted to support existing biases, whereas observing a user struggle with an interface provides objective, undeniable context that is impossible to ignore.
• Developers sometimes fear direct user contact because it creates friction, but this friction is exactly what ensures a product remains valuable. A lack of interaction often suggests the work is disconnected from the user's actual needs or that the developers are focused on the wrong incentives.
• The modern software industry suffers from excessive technical churn and complexity compared to past eras. Much of the bloated team structure seen today is a result of managing dependencies and constantly shifting stacks rather than solving the underlying domain problems.
• There is a pervasive "Product Development Antipattern" where stakeholders offer low-signal, positive feedback based on hypothetical features they will never actually use. Real validation requires critical thought and observation of actual usage patterns rather than seeking approval.
• "Leaving things alone" and resisting the urge to build "platforms" or unnecessary features is an underrated engineering skill. Many companies suffer from a desire to scale or expand their scope prematurely, losing focus on the essential, "boring" problems that actually provide value.
• In B2B environments, bloated, complex software often outperforms simple, functional alternatives because the buyers prioritize ongoing service, features, or vendor relationships over pure software efficiency.
• The "insanity" observed in the industry is often just a reflection of standard corporate dynamics, where bureaucratic maneuvering, credit-seeking, and shifting goalposts occur regardless of the specific field or product being built.
• Ultimately, software is a tool meant to serve a user's goals. When developers lose sight of this and focus on internal complexity, abstract metrics, or resume-driven development, they drift away from the practical reality that makes software useful.
The discussion highlights a fundamental tension between the pursuit of software as an abstract, scalable endeavor and the grounded reality of solving actual user problems. There is a strong consensus that isolation from the end-user—whether self-imposed by developers or enforced by management layers—is a primary driver of inefficiency and frustration. Participants suggest that while analytics and project management have their place, they often serve as thin veneers for decision-making that ignores the human experience, leading to products that are over-engineered and under-utilized. Ultimately, the most successful approaches involve a disciplined commitment to simplicity and a willingness to confront the realities of user behavior, even when that feedback contradicts internal assumptions or corporate agendas.