Excellence vs Pragmatism

I've been thinking about the relationship between excellence and pragmatism in IT. There seems to be a dichotomy between these two mindsets. Why is that?

Some believe that excellence means obsessing over technical perfectionism while ignoring everything else. With this approach, one might spend an entire week refactoring a single function or method. Others believe that pragmatism means cutting corners and not caring about quality at all. Both are extreme and incorrect understandings.

But even if we discard these fallacies, there's still a tension between excellence and pragmatism. So, how do we resolve it? Sandro Mancuso, the author of The Software Craftsman, offers a reasonable solution: we must understand and respect valid constraints (pragmatism) and do the best work possible (excellence) within those boundaries.

Constraints might include deadlines, budgets, skills, organizational structure, or the current state of the software. So, the first step is to identify these constraints clearly—know your boundaries. To do this effectively, you need to build strong relationships with business stakeholders, such as product owners. Understand what they need, and explain what you can realistically deliver.

Some constraints are fixed or very rigid—like a Christmas launch date or entrenched organizational structures. Others can be mitigated or even eliminated. For example, ensure you’re not slow because of incompetence: keep learning and practicing.

To summarize, you don’t want unbounded or unconstrained excellence. You want excellence within pragmatic boundaries.

PS: I think excellence is related to the classical understanding of freedom, which might be described as the freedom for excellence. On this reading, freedom is the disciplining of desire so as to make the achievement of the good, first possible, then effortless. Thus, I become increasingly free in my use of Golang the more my mind and will are trained in the rules and idioms of Go.