The Paradox of Software Failure: Why Resources Alone Can't Solve Bad Code

For decades, organizations worldwide have operated under a profound misconception: that bad software results from insufficient funding. As Li Hongyi astutely observes in his ETHOS article, this assumption collapses under scrutiny when billion-dollar airlines deploy inferior flight apps compared to student projects, or when corporate IT systems with massive budgets become monuments to frustration. The uncomfortable reality is that software failure stems not from resource constraints but from fundamental misunderstandings of software's unique nature and how to manage its creation.

The Management Fallacy

Traditional project management approaches guarantee failure through predictable patterns: stakeholders compile exhaustive requirement lists without defining core problems; large external teams build monolithic systems from scratch; celebrations occur at "completion" before user testing reveals catastrophic flaws. By then, budgets are exhausted and knowledge has evaporated. This cycle persists because organizations treat software like physical construction projects – predictable, linear endeavors controllable through rigid specifications and resource allocation. Software defies these constraints.

Three Inescapable Software Truths

Hongyi identifies intrinsic characteristics that make software uniquely resistant to conventional management:

1. Reusability Accelerates Progress Modern development leverages existing components rather than building from zero. Open-source ecosystems (Cassandra, TensorFlow) and cloud services (AWS, Azure) provide sophisticated, battle-tested foundations. As Hongyi notes: "You cannot make technological progress if all your time is spent rebuilding existing technology." This reuse economy enables small teams to achieve disproportionate impact by standing on giants' shoulders.

2. Complexity Is the True Constraint Software usefulness plateaus not from lack of features, but from complexity overload. iTunes' fragmentation into three apps exemplifies how accumulated features eventually degrade usability. Engineering progress halts when technical debt – the hidden cost of messy code – cancels out new development. "Human minds can only handle a finite amount of complexity," Hongyi writes, emphasizing that sophisticated systems require rhythmic cycles of expansion and simplification.

3. Knowledge Outlives Code Software's real value resides not in written code but in the collective understanding of its creators. When external vendors depart or internal knowledge evaporates, systems degrade into incomprehensible patchworks. "Software should be treated not as a static product," argues Hongyi, "but as a living manifestation of the development team's collective understanding." This explains why vendor handoffs and staff turnover cripple long-term maintenance.

Principles for Sustainable Software

From these truths emerge actionable principles:

1. Radical Simplicity First Avoid "one-stop-shop" ambitions. Successful systems like Parking.sg began as focused solutions (processing 1.1M+ sessions despite 200 unimplemented features). Hongyi advocates priority-tagged requirements: "Software projects rarely fail because they are too small; they fail because they get too big."

2. Embrace Strategic Failure "Building software is not about avoiding failure; it's about strategically failing as fast as possible." Rapid iteration exposes flawed assumptions early. When developing Parking.sg, one afternoon with parking officers revealed their real pain point wasn't coupon calculations (as assumed) but driver confusion – redirecting the entire project. Beware bureaucratic goals masquerading as user problems.

3. Engineer Quality Multipliers Elite engineers aren't just faster; their superior decisions create compound advantages. They maximize reuse, automate routine work, design robust systems, and possess disproportionate problem-solving abilities for critical edge cases. Hongyi cites "The Mythical Man-Month": adding engineers slows projects unless supported by exceptional talent. Small elite teams outperform large average ones because "you cannot have security without simplicity."

The Living System Imperative

Hongyi's most profound insight reframes software as an evolving organism. Post-launch marks not completion but intensified engagement: automated monitoring (Parking.sg's payment discrepancy checks), continuous refinement, and knowledge preservation. In this paradigm, "good software" isn't a delivered artifact but a sustained capability to solve real problems through disciplined adaptation to complexity's inexorable growth.

Ultimately, Hongyi dismantles the industrial mindset plaguing software development. Success requires acknowledging that software is an epistemological endeavor – less about writing code than cultivating organizational learning. Those who understand this shift can escape the failure cycle; others will remain baffled why money alone cannot fix their crumbling digital foundations.