How do you balance SOLID principles with pragmatic software development?

Balancing SOLID with pragmatism requires knowing when to apply each principle. The key heuristic is proportionality to volatility and consequence: apply SOLID rigorously where code is likely to change, is mission-critical, or is shared across teams. Apply it lightly for throwaway scripts, glue code, or areas unlikely to evolve. Pragmatic rules: (1) Wait for the second variation before introducing an abstraction (YAGNI first, then OCP); (2) Don't inject dependencies that have only one implementation and are unlikely to change — the abstraction adds indirection with no benefit; (3) Start with simple, working code and refactor toward SOLID when pain is felt (tests become hard, change causes regressions); (4) In rapidly prototyped features, accept some SOLID debt, then pay it down before the feature goes to production. SOLID is a tool, not a dogma.