The economy of software just flipped
14 hours ago
- #software-modularity
- #engineering-practices
- #LLM-impact
- There is a cognitive dissonance in engineering teams: using LLMs for faster coding while maintaining outdated modularity philosophies.
- Modularity has traditionally mattered due to human cognitive limits and economic benefits, reducing mental overhead.
- A brief history of modularity shows consistent goals: making code cheaper to understand and write, from subroutines to microservices.
- The economy has flipped: reading and writing code are now cheap due to LLMs, but reviewing, shipping, reverting, and downtime are expensive.
- A new modular philosophy focuses on modules as isolated, replaceable units for blast radius control, not human comprehension.
- Runtime code path control via feature flags (like Flipper) is non-negotiable, making reverting cheap and enabling faster shipping.
- When requirements change, write new modules from scratch instead of updating old ones, allowing coexistence and gradual rollout.
- Modules should not share internals; duplication is acceptable for independent replaceability.
- Review questions shift from code craft to whether a module can be turned off without affecting others.
- Public interfaces need stability, enforced by tools like Packwerk in Rails, though still pending in practice.
- Similarities with Erlang philosophy include small, focused modules, 'let it crash' mentality, and preferring rewriting over abstraction.
- Uncomfortable conclusions: refactoring becomes an anti-pattern, AI-generated code may be sloppy, modules will break routinely, and engineers must trade pride in internal design for system resilience.
- The core shift: modularity now aims to minimize risk and blast radius, treating code as disposable for safer shipping and faster recovery.