The Quest for Architectural Purity
In the evolving landscape of software engineering, the late Joe Armstrong, co-creator of the Erlang programming language, remains a foundational figure whose philosophies continue to spark debate. His 2014 essay, “Minimal Viable Programs,” serves as a manifesto against the encroaching complexity of modern software development. Armstrong’s central thesis is that the industry has become overly reliant on external dependencies, leading to a state of “software bloat” that threatens the longevity, security, and understandability of our systems. By advocating for the Minimal Viable Program (MVP), Armstrong suggests a return to self-containment and radical simplicity.
The Case for Radical Minimalism
The primary argument presented by Armstrong and his proponents is that every added dependency is a liability. In the modern ecosystem, a simple application might rely on hundreds of third-party libraries, managed by tools like NPM, Maven, or Cargo. While these tools offer immediate productivity, they introduce what Armstrong viewed as a fragile house of cards. If a single maintainer deletes a repository or introduces a breaking change, the entire stack can collapse. This is often referred to as “dependency hell,” where the developer loses control over the very environment their code inhabits.
From this perspective, a program is truly viable only if it can stand on its own. Armstrong argued that a program should ideally be a single file or a small collection of files that contain everything necessary to execute the intended task. This approach ensures reproducibility; a program written today should be able to run twenty years from now without requiring a specific, deprecated version of a package manager that no longer exists. Proponents of this view emphasize that writing one’s own logic, rather than importing a massive library for a minor feature, leads to a deeper understanding of the system and significantly reduces the attack surface for security vulnerabilities.
The Pragmatic Counter-Argument: Efficiency and Robustness
Conversely, many modern developers argue that Armstrong’s vision of the Minimal Viable Program is an impractical ideal in a fast-paced commercial environment. The “Not Invented Here” syndrome—the tendency to rewrite existing solutions from scratch—is often viewed as a waste of resources. Critics of radical minimalism point out that established libraries have been battle-tested by thousands of users across millions of edge cases. A developer writing their own HTTP parser or cryptographic library to keep their program “minimal” is far more likely to introduce critical bugs than one who uses a well-maintained, standard dependency.
Furthermore, the pragmatist view holds that the complexity of modern hardware and user expectations necessitates abstraction. Users expect features like TLS encryption, complex graphical interfaces, and cross-platform compatibility—tasks that are nearly impossible for a single developer to implement in a self-contained manner within a reasonable timeframe. In this context, the “viability” of a program is measured by its utility to the end-user and its speed to market, rather than its architectural purity. To these developers, the dependency graph is not a liability but a leverage point that allows small teams to build world-class software.
Defining Viability in a Connected World
The tension between these two viewpoints often centers on the definition of “viable.” For Armstrong, viability was synonymous with sustainability and intellectual honesty. A program that requires a 500MB runtime to print “Hello World” might be functional, but in his view, it is not truly viable because it is not sustainable or efficient. He championed the idea that we should strive for the “smallest possible thing that does the job,” a concept that mirrors the Unix philosophy of doing one thing and doing it well.
However, the opposing side argues that viability is a moving target. In an era of cloud computing and microservices, the “program” is rarely a static artifact. It is a living entity that must integrate with dozens of other services. In such an environment, the ability to quickly swap components and leverage the collective intelligence of the open-source community is what makes a program viable. The overhead of managing dependencies is seen as a necessary tax for participating in a global, collaborative ecosystem.
Finding a Middle Ground
Despite the stark contrast between these philosophies, there is a growing movement toward a middle ground. Many developers are beginning to adopt “dependency budgeting,” where the addition of a new library is treated with the same scrutiny as a financial expenditure. This approach respects Armstrong’s warning about bloat while acknowledging the practical benefits of modern frameworks. By prioritizing “zero-dependency” libraries or those with very small footprints, developers can achieve a degree of self-containment without sacrificing the speed of modern development.
Ultimately, Joe Armstrong’s critique serves as a vital conscience for the industry. Whether or not one agrees with the extreme of radical minimalism, his call to examine the “weight” of our software remains relevant. As systems become increasingly opaque and difficult to maintain, the Minimal Viable Program offers a North Star for those seeking to build software that is elegant, durable, and truly understood by its creators.
Source: Minimal Viable Programs (2014)
Discussion (0)