The SOLID Skepticism Surge

In software engineering circles, the SOLID principles have long been treated as gospel. Coined by Robert C. Martin two decades ago, this acronym—Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—has been the cornerstone of object-oriented design education. But a recent, highly engaged Reddit discussion with 92 comments and 149 upvotes signals a significant rebellion brewing in the trenches. Developers are increasingly questioning whether these five commandments are the ultimate path to good design, or if they've become a source of unnecessary complexity.

Beyond the Acronym: The Core Tension

The central thesis of the discussion, which links to a blog post titled "SOLID? Nope, just Coupling and Cohesion," is provocative yet straightforward. It argues that an obsessive focus on checking SOLID boxes can lead developers astray. Instead, the post champions two more fundamental, timeless concepts: low coupling and high cohesion.

"The discussion highlights a real fatigue with dogma," says a senior engineer who participated in the thread. "We've all seen codebases where someone applied SOLID so religiously that you end up with ten single-method classes that are impossible to follow. The principles become the goal, not the means to readable, maintainable software."

Coupling and Cohesion: The Foundational Metrics

To understand the debate, we must define the challengers. Coupling refers to the degree of interdependence between software modules. Low coupling means changes in one module require minimal changes in others—a hallmark of resilient systems. Cohesion measures how closely related and focused the responsibilities of a single module are. High cohesion means a class or function does one well-defined thing.

Proponents in the Reddit thread argue these are the primary metrics of good design. SOLID, they contend, is merely a collection of heuristics—sometimes useful, sometimes not—that aim to improve these metrics. The danger arises when the heuristic is mistaken for the goal itself.

Where SOLID Falls Short: The Developer Experience

The 92-comment thread is a treasure trove of practical grievances. Several key pain points emerged:

• The Single Responsibility Paradox: How "single" is single? This principle is notoriously subjective. One developer noted, "You can split a `User` class into `UserValidator`, `UserPersister`, `UserNotifier`... but now you've traded a slightly bulky class for the cognitive load of tracking four. That's not automatically better."
• Open-Closed Complexity: The principle states software should be open for extension but closed for modification. In practice, creating the perfect abstraction upfront is often impossible. Over-engineering for hypothetical future changes is a common anti-pattern cited in the discussion.
• Dogmatic Over-Engineering: The most consistent complaint is that SOLID, especially when taught in isolation, encourages junior developers to create intricate webs of interfaces and abstractions for simple problems. This increases indirection and can make code harder to debug and understand.

A Data Point from the Field

While anecdotal, the engagement metrics of the discussion are telling. A 0.9 upvote ratio on r/programming—a subreddit known for its critical and experienced user base—indicates the argument resonates widely. This isn't a fringe view; it's a substantial reflection of professional sentiment.

The Pragmatic Path Forward: Principles as Tools, Not Laws

The consensus among the more nuanced comments isn't that SOLID is worthless. It's that its value is contextual. The principles should be applied with the end goals of low coupling and high cohesion in mind.

"Think of SOLID as a linting rule," suggested one highly-upvoted comment. "It can warn you of potential design smells, but you shouldn't be a slave to it. Sometimes you suppress the warning because the simpler, more coupled code is the right choice for now." This reflects a more modern, pragmatic approach to software design that prioritizes clarity and the ability to change code safely over rigid adherence to any specific set of rules.

Actionable Insights for Developers

So, what should a developer take away from this debate?

1. Ask "Why?" Before "Which Principle?": Before refactoring to follow a SOLID principle, ask: "Will this reduce coupling or increase cohesion?" If the answer is unclear or no, reconsider.
2. Prefer Readability Over Purity: A slightly less "SOLID" piece of code that is immediately understandable is often more valuable than a perfectly abstracted one that requires a map to navigate.
3. Embrace Refactoring: Don't design for every possible future on day one. Write cohesive, reasonably decoupled code that solves today's problem. Use SOLID principles as a guide during refactoring when change requests reveal actual pain points.
4. Teach the 'Why': When mentoring, frame SOLID not as rules, but as patterns that serve the higher purpose of manageable dependency structures and focused modules.

The Evolving Philosophy of Software Design

This Reddit discussion is a microcosm of a larger shift in software engineering philosophy. The industry is moving away from one-size-fits-all methodologies and toward context-driven, outcome-focused practices. Concepts like Domain-Driven Design (DDD), which emphasizes modeling based on business reality, and the emphasis on developer experience (DX) align with this shift. They prioritize the human elements of understanding and maintaining code over abstract architectural purity.

The 149 upvotes and vigorous debate signify that developers are critically evaluating the tools they've been given. They are seeking a design philosophy that serves the codebase and the team, not one that the codebase must serve. In the end, the most solid principle might be the simplest: write code that is easy for the next person to change. Sometimes SOLID helps get you there, and sometimes, as 92 developers are now loudly discussing, the direct pursuit of low coupling and high cohesion is the clearer path.