SOLID
Leading Dispersed Engineering Teams: A Pragmatic Approach to SOLID Principles
I’ve been leading dispersed engineering teams since 2012, and as a Gen X CTO in my mid 40s who became a software engineer later in life, I’ve seen design trends come and go. In the B2B space, where every bug can drive up churn, SOLID principles still earn their keep—so long as you treat them as guardrails, not straightjackets. In the comig days I will be writing about individual examples of these principles and how they have impacted me and my teams.
Single Responsibility Principle
I used to see eager junior developers carve every tiny behavior into its own class. Today, with microservices and serverless functions everywhere, it makes sense to give each service a clear reason to change. But in practice you don’t need a dozen one-method classes. I guide my teams to group closely related behaviors (logging, validation, business logic) into cohesive modules. That reduces boilerplate and cognitive load, while still keeping our blast radius small when something goes wrong in production.
Open-Closed Principle
Around the time I started leading teams, feature flags were just emerging. Now they’re standard. Designing code that you can extend via plugins or A/B test frameworks without touching core modules still protects us from unintended side effects. But I’ve learned that you can over-abstract. For new business logic—say a partner integration I have to stand up quickly—I’ll bend open-closed in favor of getting value out faster. For our core billing and churn-reduction services, though, strict extension-only patterns remain nonnegotiable.
Liskov Substitution Principle
In a polyglot world (my teams use .NET, Node.js, Python, and even some Go), I don’t lean on deep inheritance hierarchies. Instead, I push for interfaces or protocols that let us swap implementations without surprises. That way we can replace an email-sending service or a fraud-detection module without worrying we’ll break every consumer. Liskov’s spirit, replaceability, still guides us, even if we don’t always call it out by name.
Interface Segregation Principle
When you’re serving multiple front-ends (from our Angular dashboard to a partner API), lean interfaces reduce coupling and payload size. I’ve seen teams spin up dozens of tiny endpoints, though, and I end up asking them to build API composition layers. That gives each client exactly what it needs, without creating a maintenance headache for every new interface.
Dependency Inversion Principle
Injecting abstractions makes testing and deployment pipelines smoother and helps avoid nasty surprises when we roll out a new SQL provider or queueing system. I do insist on this in areas tied directly to churn, like our payment workflows. In performance-critical paths, however, I sometimes let my engineers wire concrete implementations directly, then refactor to inversion once we have metrics and tests in place.
Do SOLID Principles Help or Hurt?
For a mid 40s Gen X engineer-turned-CTO, SOLID feels less like a rigid rulebook and more like trusted advice. In B2B SaaS, where reliability underpins retention, these principles help avoid breaking code that impacts our customers’ bottom line. The trick is to apply them where they lift quality and velocity (our core services), while remaining pragmatic for fast-moving features.
SOLID remains a valuable north star in 2025.
It helps my dispersed teams build resilient, maintainable systems without clobbering our pace. The best engineering cultures treat SOLID as guidance: follow it when it steers you clear of churn-inducing defects, and feel free to bend it when expediency serves your customers.