×

As a pragmatist, understanding fundamentals and how they’re applied is enormously important to me. From that foundation, I can then—for the specific use case—design a suitable pattern that describes a project or an entire ecosystem. Through this, I define conventions to make later decisions unnecessary. You could probably also call them principles.

The Core Idea: Pragmatism Over Dogma

Brief retrospective: The core of Convention over Configuration was that the framework handles those decisions for you, so you don’t have to bootstrap every new project with a multitude of configuration parameters first. What’s important here is that it’s not a dogma, but pure pragmatism—so you can immediately focus on solving the actual problem.

Convention over Configuration was introduced through Ruby on Rails. It was a refreshingly new approach, and I appreciate clear conventions—code formatting, project structure, architecture, and so on. However, it becomes a disadvantage when you try to implement absolutely everything with existing conventions. Even though it’s important to be able to refer to such principles, we must ensure they remain a living component that evolves over time.

The 90% Rule for Conventions

However, every convention becomes problematic when suddenly every problem is formulated to fit into the existing rulebook. Pragmatism means, above all, going your own way with conscious decisions. Conventions may need leeway, or at least need to be extensible.

Even though it initially sounds logical that principles should be followed always and everywhere—consistency, after all—this misses the actual point. If we manage to have 90% of our projects adhere to existing conventions, only 10% remain—the uniqueness we need to work through. And if these 10% consciously break with conventions to provide a simple and straightforward solution, you’ve won twice over. No artificial attempt was made to enforce a rule; instead, you created an easily understandable and maintainable deviation.

Conventions as Guardrails

Conventions should be guardrails. They ensure that we find our way around a wide variety of projects quickly. Understanding conventions and principles is the foundation for leaving this path at the right time, because through this understanding you also know the boundaries that work wonderfully in most cases.

This approach became enormously important when I started working with Go many years ago. A language that in its early days provided no frameworks whatsoever—it prescribed no deep structure and offered nothing else. You were on your own. Creating conventions brought clarity and quick project successes, which I still appreciate today.

For more on the tension between structure and flexibility, see The Two Faces of Abstraction: Power vs. Hidden Dependency and Reclaiming Pragmatism in Software Development.

Further Explorations

• Convention Over Configuration—Wikipedia
• The Rails Doctrine
• YAGNI—Martin Fowler
• The Pragmatic Programmer

Have thoughts on this article? Join the discussion on —I’d love to hear your perspective!