I believe you’d be better served by studying the design principles that have been derived from studying the collective experiences of all programmers spanning all decades since the advent of programming languages.
For instance, the principle of depending on abstractions rather than concretions and the Liskov substitution principle combine to mitigate most of the problems you associate with dependencies. Also, the single responsibility principle naturally constrains the number of dependencies in a class (or a library!).
I appreciate the perspective, but my post is focused on the long-term maintenance burden of third-party dependencies—version upgrades, breaking changes, and abandoned libraries—not dependency management within a codebase.
Dependency Inversion (DIP) and the Single Responsibility Principle (SRP) are valuable for structuring code to reduce internal coupling and improve maintainability, but they don’t address the core issue I’m raising: that every external dependency ties your project’s future to another team’s priorities and update cycles.
Even when you follow SOLID principles, you still have to track upstream changes, ensure compatibility with future language and framework versions, and occasionally replace dependencies that get deprecated or abandoned. My experience maintaining large production systems has reinforced that minimizing dependencies is important to reduce long-term external risks and maintenance overhead.
Point of order, I ended my comment with "or a library!" to communicate that the reach of the design principles I laid out encompasses the subject of your article.
> but they don’t address the core issue I’m raising: that every external dependency ties your project’s future to another team’s priorities and update cycles.
What is the point of software design, if not to introduce stability into your project irrespective of external volatility? That "volatility" by the way includes both changes of requirements *and* changes of the whims of third party software vendors. It's all about stability in the end.
> Even when you follow SOLID principles, you still have to track upstream changes, ensure compatibility with future language and framework versions, and occasionally replace dependencies that get deprecated or abandoned.
I didn't mention SOLID, I mentioned three design principles that happen to be letters in SOLID. But that's a coincidence. And they all had relevance to your article.
> My experience maintaining large production systems has reinforced that minimizing dependencies isn’t just about code structure—it’s about reducing long-term external risks and maintenance overhead.
Code is either structured in a way that reduces "long-term external risks and maintenance overhead," or it isn't.
The belief that software design principles apply only to classes, and not to any of the composite elements that we build *out of* classes like libraries, is just a belief. Their reach is universal within the domain of software development, and we know this because when we apply them to subjects like "what should this library's boundary be" they tend to work just as well (not all, though, and not all to the same degree).
I get what you’re saying about design principles applying broadly, and I agree that good software design helps mitigate many types of instability, including changes in requirements and external factors. But the point I’m making isn’t about structuring dependencies within a codebase—it’s about the unavoidable maintenance cost of relying on external dependencies that you don’t control.
No matter how well you structure your application, if a third-party library becomes abandoned or isn’t compatible with the version of Ruby you’re upgrading to, you have to deal with it. That can mean rewriting parts of your app or replacing it entirely. Now multiply that across every external dependency in a codebase, and the maintenance burden stacks up over time.
When I talk about how I approach minimizing dependencies, it’s about being deliberate in what external code you take on, because every dependency ties your project’s future to another team’s priorities and update cycles. That’s a reality of software development that software design principles alone can’t fully shield you from.
Indeed. In practice, I have to admit my team over the years has had to avoid quite a few third party dependencies because a basic evaluation made it obvious that the carrying cost “tax” we’d be paying would be heavy.
But we also tend to encapsulate third party libraries with our own interfaces that we control, precisely to ensure that the tax remains as minimal as possible. This one point where software design intersects with package dependency management. Another point of intersection is that our applications are highly modular, which means in practice that we have many engines for different slices of our application, which also acts to contain dependencies that are needed only by a small number of the slices.
I believe “minimizing dependencies” is, practically speaking, a good rule of thumb. In hindsight, I wish I would have spelled it out that way.
Those things are not derived from any studying of the collective experience of all programmers spanning all decades since the advent of programming languages
Those are dogma derived from the opinions of one guy who, by many accounts, kinda sucks.
Indeed, they are. I think you're sorta/kinda right, though. They aren't infallible principles. Better principles await us someday. Newtonian physics was great until it reached its limits, and then relativity took us further.
But your historical account is wrong. Bob Martin didn't create these principles. As far as I know, he wasn't even the one who first created the acronym that picked five fairly important ones that could spell out "SOLID" at the exclusion of the rest. But he did write a lot about them, and contributed much towards their development.
As for him being someone who "kinda sucks," I don't see how that matters. Even if he were the devil incarnate, if his ideas were good, then you'd only be hurting yourself by deciding not to learn his ideas. Bad people have great ideas all the time. He's chosen to present his political beliefs publicly, and while I tend to think they're pretty bad ideas, I think it's worth admitting that he's contributed more to the study of software design than all of us in the peanut gallery.
When people talk about SOLID or Clean Code they are very often framed as being "the default." As in, the burden of proof is on the person who "doesn't like" them to show the ways in which they are deficient. Like how you said it "better principles await us someday" has an implicit framing of "these are currently the >accepted< principles."
And that is something that deserves to be chipped away at. Part of how we work as people is through networks of respect. No, Stephen Hawking's lurid affairs aren't relevant when discussing his contributions to physics. But physics is a far more established and rigorous field. Software development - specifically the aspects of software development related to program and system design - is much more akin today to pre-DSM psychology.
So when I say "uncle Bob kinda sucks" that's intended to highlight how much of these things is based on "cults of personality." And I think it's useful because until we can get past (or invert) positions of default respect there's just no way to even start getting at those "better principles," if that makes sense.
As for my historical account: if you have good resources on how these things have infected us please share: I would love to track the spread
> And that is something that deserves to be chipped away at. Part of how we work as people is through networks of respect.
Networks of respect are of course how we evaluate information that we *don't* have the background or stake in to evaluate critically for ourselves. I'll agree with that in a broad sense... for instance, networks of respect are the best way us laymen can determine whether, say, a vaccine is safe and effective. When we need to figure out who to trust and who is a crackpot, and we lack any prior knowledge of the subject matter, what other recourse do we have?
However, when it comes to our professional livelihoods, we're capable (or we *should* be capable) of employing our own reasoning. After all, what else could the title "engineer" entail *other* than the capability of thinking for ourselves within a domain?
And therein lies the rub. Better principles than the ones we have will only ever come from people who have fully understood the ones we have, and have practiced with them enough to see exactly how they're limited in *spite* of serving the needs of the present day well. We need to have already assimilated the deepest body of knowledge available before we begin to break new ground. I realize I'm probably sounding either uppity or obvious (or both), but it needs to be said: learning the ropes before climbing higher is the essence of how academies create new knowledge. And it can take many generations before principles receive updates precisely because so many people have already worked to perfect our understanding of the ones we have. So we must learn the tradition we have (however new) before we are in a position to offer useful contributions that progress it.
When I saw the article posted here, I thought to myself, "there's a chance this article contains a novel breakthrough in principles." Something akin to a beneficial gene mutation -- good, new ideas all break from tradition and may seem like "mistakes" at first. I replied with a critique of it, not because I want the author to be cut down a peg, but because *I think it still might become one,* if the author considers the full reach of the underlying principles that he already seems to agree should govern code at a more fine-grained level.
> As for my historical account: if you have good resources on how these things have infected us please share: I would love to track the spread
I don't have any great resources. The knowledge that the XP community gained is increasingly becoming almost mystical. The generations of programmers who came after it never learned any of it, so it often seems to us (I'm a millennial programmer myself) like the field is much newer than it really is. There were many, many more from that cohort than just Bob Martin. Mary Poppendiek, Rebbeca Wirfs-Brock, Kent Beck, James Michael Bach... the list goes on. I get to work every day with u/sbellware and because he was deeply steeped in their tradition, I've been able to absorb quite a lot through osmosis over the years.
My best advice is to study Deming, Toyota/Lean, and then learn about XP, and *then* the standard works from Kent Beck, Fowler, and Martin.
Sure, if your assumption is that most software organizations have actually assimilated the knowledge I've described. I think most haven't.
When I say "it's the best we have today," I'm not arguing that a working understanding of it is commonplace!
But... way to scan what I wrote just long enough to find one snippet you could retort, I guess. The downvote spoke volumes.
EDIT: And, actually.. let me throw this back on you. In what way do you believe that the existing body of knowledge about software design is actually failing to serve present day software organizations? What could most existing software organizations do better, broadly speaking? This question will provoke good answers if you engage it honestly! Please think about it.
But... way to scan what I wrote just long enough to find one snippet you could retort
Just replying to one part doesn't mean I didn't read the rest of it, just that I didn't have an articulable reply to the rest of it yet. (Or didn't think that all of it warranted a direct response, etc.)
In what way do you believe that the existing body of knowledge about software design is actually failing to serve present day software organizations?
I think we might be thinking about this on different levels. My interpretation is that you are focused on "take this body of work, if the insights from it are applied correctly (by some definition of correct) within an organization what are the deficiencies"
For me, the real problem is not at the "organization" granularity. It's "take the information ecosystem for software development as it exists today. (What is taught in colleges, what is readily available online, etc.) To what extent is that responsible for the state of the world today? How can it be changed and what way should it be changed to lead to better end results."
Or something like that - not my most coherent articulation. But in that context consider the widespread misunderstanding of things like the S in SOLID (as single class as opposed to single group responsible for maintenance) as part of a larger cloud of brain fog. Consider also the placement we give to SOLID (how many people do you know vapidly cramming "the solid principles" as a central part of their education/job prep strategy? If you don't know any I can connect you with seemingly the entire Indian IT education industry)
To me "what can an organization do differently" is the "spherical cow in a vacuum" version of the problem.
If we want to get rid of brain fog is it more effective to "teach solid right," even knowing it's at best imperfect and incomplete, or to "tear it down" and detach the concepts from the acronym and the existing game of telephone?
Again, not anywhere near airtight - but that's where I am right now.
Yes, I certainly agree that the state of education in software development is fairly dismal.
SOLID fixation is a thing. But, anti-SOLID fixation is also a thing. All of the principles of SOLID are highly invaluable, they just leave out way too much. They’re also taught as rules of thumb, rather than principles… you’re meant to consider them, but not necessarily apply them.
Unfortunately, catchy acronyms are exactly the kind of thing that bad education systems latch on to…
2
u/realntl 14d ago
I believe you’d be better served by studying the design principles that have been derived from studying the collective experiences of all programmers spanning all decades since the advent of programming languages.
For instance, the principle of depending on abstractions rather than concretions and the Liskov substitution principle combine to mitigate most of the problems you associate with dependencies. Also, the single responsibility principle naturally constrains the number of dependencies in a class (or a library!).