I have a theory that software drives people insane
Software’s intangibility and low perceived cost of change are argued to encourage constant redesign, overcomplicated architectures, and faddish methodologies, which in turn create chaotic workplaces and burnout. Commenters link this instability less to code itself than to incentives around hyper-growth, analytics‑driven feature churn, and managers who are detached from users and implementation effort. Many advocate tighter feedback loops with real users, “dogfooding” one’s own products, and resisting unnecessary change as practical ways to restore sanity and build simpler, more reliable systems.
Handwashing tangent and “sanity” baseline
- Thread opens with debate over whether frequent handwashing is “insane” today.
- Several mention washing more post‑pandemic and feeling less sick.
- Cochrane review on physical interventions is cited: modest but uncertain benefit from hand hygiene; low adherence weakens results; masking evidence also uncertain.
- Others recall prior HN arguments that “dirty hands” can be beneficial.
- Some argue that judging sanity from such habits shows the article starts from a shaky premise.
Developers, users, and organizational structure
- Many argue it’s not software per se but building it in isolation from users that “drives people insane.”
- Direct, regular contact with customers (including doing first-level support) is seen as grounding and clarifying.
- When communication is mediated only by project/product managers, requirements get distorted, priorities become politics, and devs lose touch with real problems.
- Some say devs themselves often resist user contact, considering it a distraction; others call that attitude unprofessional but note misaligned incentives (performance tied to ticket throughput).
Analytics vs. usability and feature decisions
- Heavy reliance on analytics without context is criticized.
- Common pattern: rarely used features are removed based on raw usage counts, ignoring critical-but-infrequent workflows and discoverability issues.
- Example: removal of a browser’s “close tabs to the right” option justified by low click rates; commenters argue low frequency ≠ low importance.
- Management sometimes “manufactures” data (burying features first) to justify cuts.
- Usability research and watching people struggle with interfaces repeatedly contradicts analytics-derived hypotheses.
Dogfooding, empathy, and their limits
- Using one’s own software is praised as a powerful way to avoid insanity and quickly spot friction.
- This is credited with better accessibility and more trustworthy, low‑friction workflows.
- However, dogfooding can mislead when developers use the product in narrow, expert ways that don’t match typical users.
Tech churn, complexity, and industry culture
- Several contrast small, focused teams in the past delivering critical systems with today’s large teams shipping over‑engineered CRUD apps.
- Tech churn and bloated toolchains are blamed for wasted effort and cognitive overload, exacerbating the “insanity.”
- Others argue the real driver is money and competitive hype: everything must be a “platform” or “data company,” so trivial products are reframed as world‑changing.
Nature of software and expectations
- Software’s intangibility and malleability encourage constant change; cost of change is perceived as low, so everything becomes urgent.
- Users often treat software output as authoritative and trustworthy; when bugs or propagation delays appear, they experience disproportionate anxiety.
- Some see software as simply revealing pre‑existing human ego, delusion, and corporate dysfunction rather than uniquely causing them.
Reception of the article
- Many found the post relatable and funny, capturing real industry dysfunction.
- Others thought it rambling, under‑structured, and overlong, with a weak or muddled central thesis.