Welcome back. In our previous lesson on Jakob's Law, we focused on the power of convention in design, showing how aligning with users' existing mental models creates an efficient and intuitive experience. We saw that good design often works by not making the user think.
Today, we confront a powerful force that often undermines such elegant simplicity: the relentless tendency of systems to grow more complex over time. This lesson examines Wirth's Law and Zawinski's Law, two principles that describe how software and systems often become bloated with features, sometimes getting slower even as the hardware they run on gets faster. Your goal is to apply these laws to observe how the tools you use—for lingerie design and relationship communication—can suffer from this uncontrolled growth, outpacing both hardware capabilities and your own capacity to use them effectively.
As an efficiency expert, you're familiar with systems that accumulate inefficiencies. These laws provide a name and a framework for one of the most common sources of digital inefficiency: feature creep.
The Inexorable March of Bloat: Wirth's and Zawinski's Laws
Wirth's Law states that "software is getting slower more rapidly than hardware becomes faster." As processors and memory improve, developers are often less incentivized to write efficient code. They add more layers of abstraction and more features, and the resulting software bloat consumes all the performance gains from the new hardware, and then some.
Zawinski's Law, also known as the Law of Software Envelopment, makes a similar point with a more cynical edge: "Every program expands until it can read mail. Or is replaced by ones that can." This describes the tendency for successful applications to continuously add features, expanding their scope far beyond their original purpose, until they become large, complex, and monolithic. The ability to "read mail" is a stand-in for this ultimate, all-encompassing feature set.
Together, these laws paint a picture of "feature fatigue," where users are overwhelmed by complex, slow, and hard-to-use products. Let's explore the research behind this phenomenon.
[PDF] defeating-feature-fatigue.pdf
This article from Harvard Business Review provides a comprehensive analysis of "feature bloat." It explains the psychological and economic drivers behind it and details the negative consequences for users.
Please read the following parts of the article: Start with the introduction, from the beginning of the article up to the end of the first section, to get a clear definition of "feature bloat" and "featuritis." Next, read the section "It Slices, It Dices," which explains why manufacturers are so tempted to add features. Notice the role of low marginal cost and standard market research techniques. Now, read about the user's perspective. The sections from "What Appeals to Consumers" to the end of the third study are crucial. They show a key finding: consumers are drawn to more features before purchase but are more satisfied with simpler products after using them. As a statistician, you will appreciate this empirically demonstrated split between expected and experienced utility. Finally, read the conclusion starting from the final paragraphs to understand the broader market impact.
The core takeaway is that the drive to add features creates a paradoxical situation. What makes a product attractive on the shelf (more features) is often what makes it frustrating to use at home (poor usability).
This isn't just a theoretical problem. Let's listen to a perspective from a well-known game developer, Jonathan Blow, who is a vocal critic of modern software bloat.
Jonathan Blow on Why Modern Software is So Slow
This clip features Jonathan Blow discussing why modern software feels so slow despite massive improvements in hardware power.
Please watch the segment from his explanation of the spiral. He argues that developers' expectations for performance are set by the slow software they are used to, creating a self-perpetuating cycle of inefficiency. This is a powerful cultural explanation for Wirth's Law.
The issue is systemic. Modern development practices can even accelerate this trend. The following discussion from a developer community provides insight into one of the primary mechanisms of bloat today: dependency management.
Bloat is still software's biggest vulnerability (2024) | Hacker News
This Hacker News thread discusses the causes and consequences of software bloat in modern development.
Please read the following selected comments: Start with the top-voted comment by user GuB-42, which begins with "I am beginning to think...". This comment perfectly captures how modern tools like npm or maven make it trivially easy to add dependencies, removing the natural friction that once limited bloat. Next, read the comment by ryandrake that starts "The reason bloat doesn't get fixed...". This frames the problem in economic terms you'll recognize: bloat as a negative externality, where developers get the convenience while users bear the cost. Finally, read the comment by al_borland beginning with "A big issue is the speed...". This highlights the organizational pressures that prioritize new features over maintenance and optimization, ensuring that bloat accumulates over time.
Application 1: The Bloating of Lingerie Design Software
Imagine you are using a specialized CAD application for lingerie design, which we'll call "LaceCAD 1.0." It started as a simple, fast program that did one thing well: it allowed you to draw and grade patterns for bras and tops. It was lean and efficient.
Now, let's watch Wirth's and Zawinski's Laws take effect over several versions:
-
LaceCAD 2.0 (The Expansion): The developers, seeking to capture more of the market, apply Zawinski's Law. They add a fabric inventory management module. Then, a client database (a mini-CRM). Then, a project management suite with task lists and deadlines. Finally, they add a "collaboration" feature with its own messaging system and, eventually, the ability to send and receive emails directly from suppliers within the app. LaceCAD can now "read mail."
-
LaceCAD 3.0 (The Slowdown): All these new features are built using modern, high-level frameworks with sprawling dependencies, as discussed in the Hacker News thread. The developers, working on powerful new machines, don't notice any performance issues. But for you, on your perfectly adequate two-year-old computer, Wirth's Law hits hard.
- The application now takes 45 seconds to load, compared to the 5 seconds of version 1.0.
- Simple, core actions like adjusting a curve on a bra cup pattern now lag, as the software's bloated codebase competes for system resources.
- The user interface is now a cluttered mess of icons and menus for features you never use, making it a chore to find the basic drawing tools you need every day. The minimalist tool has become a bloated suite.
This is "feature fatigue" in action. The tool, which was meant to enhance your efficiency, has become a source of friction and cognitive overload. Its complexity has grown faster than your hardware can handle, and certainly faster than your patience can. You might start looking for a replacement—perhaps a simpler, more focused tool that does less but does it better, proving the second part of Zawinski's law: bloated programs are eventually replaced by ones that can actually do the job.
Application 2: The Relationship Management App Trap
Now, let's apply this to the management of a vee relationship involving a wife (Anna), her husband (Bob), and her boyfriend (Charlie).
-
Initial State (The Lean Approach): The three partners start by using a set of simple, distinct, and effective tools. They use a shared Google Calendar for scheduling dates and commitments, a Signal group chat for day-to-day logistics, and a shared document for their relationship agreements. Each tool does one thing well.
-
The All-in-One Solution (Zawinski's Law): Seeking to "optimize" their relationship management, they subscribe to a new app called "PolySync." It was originally just a calendar, but it has since expanded. It now includes:
- A color-coded schedule for up to five partners.
- An "emotional check-in" module with mood tracking and journaling.
- A "compersion level" tracker.
- A library of articles and podcasts on polyamory.
- A direct messaging system that integrates with their email to send daily summaries. PolySync has, metaphorically, expanded until it can read mail.
-
The Usability Cost (Wirth's Law): The app is a prime example of feature creep, vividly illustrated by the game development case study below.
A Case Study on Overscoping and Feature Creep
This video, "A Case Study on Overscoping and Feature Creep," shows a game development team's project spiraling from a simple idea into a massively complex one. It's a perfect real-world example of the process we're discussing.
Watch how the team's brainstorming session evolves. They start with a "very simple very safe idea" but quickly add dozens of new mechanics and features from brainstorming to implementation. By the end, they reflect on how they "overscoped big time" because their "content heavy game" required so much custom work. The PolySync app followed an identical trajectory.
The partners' experience with PolySync mirrors the developers' regret. The app is slow, buggy, and drains their phone batteries (a literal example of Wirth's Law). The user interface is a confusing maze of features they don't need.
- Instead of facilitating connection, the app creates friction. A simple scheduling question that would take 30 seconds in a group chat now involves navigating through the app, triggering unwanted notifications.
- The quantitative "mood trackers" feel reductive and create pressure to perform happiness, turning a tool for connection into a source of anxiety—a perfect example of Goodhart's Law, which we will revisit later.
- They spend more time managing the app than connecting with each other.
Ultimately, they suffer from relationship tool fatigue. They abandon PolySync and return to their original, simpler system—a calendar, a chat app, and a document. The bloated system is replaced by a set of lean tools that actually work.
Conclusion
Wirth's and Zawinski's Laws offer a crucial warning for anyone designing or using complex systems. The temptation to add "just one more feature" is immense, but the cumulative cost is paid in performance, usability, and user satisfaction. Unchecked complexity is a form of systemic inefficiency that can cripple even the most promising tools.
Key Takeaways:
- Wirth's Law: Software's expansion in complexity and abstraction layers often outpaces hardware improvements, leading to slower, not faster, applications.
- Zawinski's Law: Successful programs tend to suffer from "feature creep," expanding their scope until they become bloated and unwieldy monoliths.
- Feature Fatigue: The end-user experience of being frustrated and overwhelmed by products that try to do too much, but do it poorly.
- The Cost of Bloat: The consequence of these laws is not just slow software, but increased cognitive load, friction, and inefficiency for the user, whether they are designing lingerie or managing a relationship.
In this lesson, we've observed the qualitative problem of systems becoming too complex. In our next session, we will examine Claasen's Law, which offers a more quantitative perspective by proposing that the usefulness of technology follows a logarithmic curve, providing a model for the diminishing returns of technological advancement.