Software Engineering Laws - Product Development

Zawinski’s Law

Every program attempts to expand until it can read mail.

This law is a cynical but accurate observation on the lifecycle of successful software. The natural trajectory of any useful program is to accumulate features until it becomes a bloated, unfocused platform. The reference to “reading mail” is metaphorical; it represents the ultimate, all-encompassing “platform” feature that is completely disconnected from the program’s original purpose. The law is a warning that feature creep is not an accident but an inevitable gravitational force that must be actively resisted.

Why it happens:

• Success Attracts Requests: A program’s success is its own worst enemy. The more users it acquires, the more diverse their needs become. These users will relentlessly request features to solve their adjacent problems, pulling the product in countless different directions to avoid having to switch to another tool.
• The Feature Parity Arms Race: The competitive landscape creates immense pressure to match the feature set of rival products. This leads to a reactive development cycle where the roadmap is dictated by a competitor’s checklist rather than a coherent product vision.
• Organizational Gravity: It is often easier for a product team to justify its existence and demonstrate progress by shipping new features than by doing the less glamorous work of refining, simplifying, or removing existing ones. The product’s expanding surface area becomes a proxy for the team’s output.

What to do about it:

1. Have a Written and Enforced Product Vision: The most potent defense is a clear, concise vision statement that defines what the product is and, more importantly, what it is not. This document serves as a constitution, providing a framework for saying “no” to requests that don’t align with the core purpose.
2. Make “No” the Default Answer: Every new feature should be considered guilty until proven innocent. The burden of proof must be on the proposed feature to demonstrate overwhelming value and alignment with the vision. A culture of strategic refusal is essential to protect the product’s focus and prevent the accumulation of “barnacle” features.
3. Focus Relentlessly on the Core “Job to be Done”: Sharply define the primary problem your users “hire” your product to solve. Every feature decision should be evaluated against a single question: “Does this help the user do that core job better?” If the answer is no, the feature is likely a distraction.
4. Favor Integration over Assimilation: Instead of building every requested adjacent functionality, provide robust APIs and integrations. Let other best-in-class tools handle those jobs. This allows your product to be a powerful, connected part of a user’s workflow without absorbing the complexity and maintenance burden of becoming a monolithic “everything-platform.”

Atwood’s Law

Any application that can be written in JavaScript, will eventually be written in JavaScript.

This law is less a statement about the technical superiority of JavaScript and more a profound observation on ecosystem gravity and the path of least resistance. It recognizes that the language with the greatest ubiquity, the largest repository of pre-built solutions (npm), and the ability to run on both the client and the server holds a powerful, gravitational advantage. Developers will inevitably use the most convenient and accessible tool, and for a vast spectrum of modern applications, that tool is JavaScript.

Why it happens:

• Unavoidable Ubiquity: JavaScript is the only language that runs natively in every web browser on the planet. This gives it a unique and unassailable beachhead. Any application with a web component must interact with JavaScript, making it a constant presence.
• The Full-Stack Advantage: The advent of Node.js allowed developers to use a single language, toolchain, and mental model across the entire stack. This dramatically reduces cognitive overhead and simplifies team structure, making it the most efficient choice for many organizations.
• Ecosystem Gravity: The npm registry is the largest software library in the world. The answer to “how do I solve X?” is almost always a quick npm install away. This creates a powerful feedback loop: more developers lead to more libraries, which in turn attracts more developers.
• Low Barrier to Entry: The accessibility of JavaScript creates a massive global talent pool. It’s easier to hire for and easier for new developers to start with, ensuring its continued dominance in the workforce.

What to do about it:

1. Acknowledge JavaScript as the Default: For many standard web applications and services, JavaScript/TypeScript is the default, baseline choice. You must have a strong, specific, and evidence-based reason to deviate from it. Fighting this default for dogmatic reasons is often a poor business decision.
2. Define Your “Escape Hatches”: Identify the specific domains where JavaScript’s weaknesses are a critical liability for your product. This typically includes high-performance computing, low-level systems programming, or complex data science. For these areas, deliberately choose a more suitable language (like Go, Rust, or Python) and treat it as a strategic exception.
3. Mandate a Type System: For any non-trivial JavaScript project, do not treat TypeScript (or a similar type system) as optional. Mandate it. This is the single most effective tool for mitigating JavaScript’s scalability and maintainability issues, allowing you to manage the complexity that comes with building large applications.
4. Invest in Polyglot Capabilities: While acknowledging JavaScript’s gravity, avoid creating a monoculture. Strategically cultivate expertise in a second or third language that complements JavaScript’s weaknesses. This ensures your organization has the flexibility to choose the truly right tool when the problem domain demands it, rather than just the most convenient one.