Purism or Pragmatism: Two Approaches to Development Culture

The debate between tradition and progress is as old as Western civilization itself. In every field of human activity, from philosophy to science, purists and pragmatists have clashed over which approach is more reliable.
Strangely enough, even the business world—a social environment known for its rather pragmatic outlook—is not immune to these arguments. Software developers, managers, and data scientists have all, at some point, faced the tension between adherents of a particular methodology or style and those who prefer an eclectic approach.

Understanding the Core of the Debate

We have chosen to use the terms “purist” and “pragmatist” to label each side of this argument. There is no philosophical subtext here; we simply found these terms clear enough.
By purists, we mean traditionalists or people with a well-defined worldview, whose values and behavior reflect that worldview as accurately as possible. Imagine a software developer who is a staunch advocate of agile or waterfall methodology and unwilling to compromise on their principles.
On the other hand, pragmatists are people with a flexible mindset. They are less interested in following a methodology and more focused on the result. If we had to sum up their core belief in one sentence, it would be “whatever works.”
Reality is rarely this clean and easily defined, so instead of viewing this division as two sides of a coin, it is more accurate to think of it as a continuum. Most of us are not strict purists or pragmatists; we have a bit of both.
Some of us enjoy the structure of methodologies, while others prefer the freedom and creativity of a more open approach. Either way, most of us are willing to compromise under the right circumstances. Unfortunately, that is not always the case, and that is where we can find ourselves at an impasse.

When Methods Matter

When a friend of ours conducts a workshop, he always tells a rather funny story. When he started working as a software developer, his first job was at a company that proudly declared it was 100% object-oriented development.
In our friend’s first project, the team reached a dead end because they had a problem that was not easy to model using an object-oriented approach. Our friend suggested a couple of solutions, both of which required imperative programming, but his ideas were rejected because they did not fit the company’s style.
As funny as it sounds, this is a true story, and you would be surprised how common it is. And it is not necessarily limited to programming paradigms. Advocates of waterfall or agile can be just as rigid in their positions as that company was in its approach to software development.

There are countless reasons why this happens. One is the sunk cost fallacy: some companies have invested so much time and effort into mastering a certain approach that they apply it to everything, even when it was never intended for that purpose.
I lean toward a less cynical explanation. People are creatures of habit and tradition; societies are built on a foundation of rituals. By society, I mean everything from civilization to the family, including companies.
A company’s identity is partly defined by its practices and traditions. Frameworks and methodologies provide a common language for all members of the company, serving as semantic shortcuts. They allow us to quickly exchange information with people who share our views.
When we operate outside that worldview, communication becomes more difficult, it is harder to get the point across, and we risk breaking patterns or even alienating ourselves from the community.
For example, imagine a company that vigorously adopts Six Sigma, except for one department whose manager stubbornly sticks to other forms of process improvement.
If you, as a consultant, were auditing the performance of each department, you would have a harder time with that department because its approach differs from the rest, making it more difficult to evaluate its effectiveness compared to others.
Returning to my friend, he was right, but what if they implemented his solution, and a few years later another team inherited the project and discovered this strange imperative code in object-oriented software? They might find it harder to understand how that code is supposed to work.
Innovation is disruptive by nature, so it is not uncommon for it to face resistance, especially when that innovation clashes with the core values or social norms of a group.

The Pragmatic Developer

Now imagine the polar opposite—a software developer who builds their project on pure pragmatism: if it works, it works. I would be the first to agree that for most of us, that would be great—the ability to write code however we want.
Unfortunately, it is simply unrealistic. When we write code, especially for others, we have to understand that we might not be around forever. So our work cannot be idiosyncratic; it must be able to convey intent, and it must have structure so that others can follow it.
Of course, this is again an extreme example. Pragmatists are not masters of chaos; they simply believe that finding a solution to a problem is more important than adhering to a set of specific norms or traditions that may be constraining.
Perhaps the clearest example of pragmatic developers are those who use hybrid methodologies, combining the structure of a waterfall approach with the fast delivery and user involvement typical of agile.
A common trait among pragmatists tends to be their level of experience. Senior developers are more likely to experiment and rely less on traditional approaches.
For instance, the vast majority of people working with Clojure (a functional programming language on the JVM) are senior developers who got tired of working with object-oriented programming.
And this is not unusual. As Kuhn argues in his book on scientific revolutions, every paradigm has a limit, a point where it breaks down. That is when the specialist realizes that a new paradigm is needed to solve their problem.
If structure provides a common framework, then innovation is what pushes that framework to its limits. The alternative is rather grim: traditionalism fosters stagnation. If we stick to our safe and reliable methods, we will reach a point where we simply cannot adapt.
And that is the last thing we need in a business that is accelerating by the minute.

Opposites Complement Each Other

Our lead specialist at ESK Solutions fully understood that opposing forces are not counterproductive; on the contrary, when in balance, they reinforce each other.
Pragmatism and purism are not opposites in the sense that one approach excludes or negates the other. Adhering to your methods can create structure, while trying new solutions can push boundaries.
In my personal opinion, understanding the value of each approach and fostering a culture that values both is the best path to building a flexible company with a strong core that can adapt while retaining its essence.