The history of humans debating over the value of tradition versus progress is as ancient as Western Civilization itself. Every field of human endeavor, from philosophy to science, has seen the clash of purists and pragmatists fighting over which approach is more reliable.
Ironically, not even the business world, a social environment known for its rather pragmatic cosmovision, is immune to this debate. Software developers, managers, and data scientists have experienced at one point or another the tension between those who promote a methodology or style and those who tend to prefer an eclectic approach.
Understanding The Debate
I’ve decided to use the terms Purist and Pragmatist to refer to each side of this debate. There is no philosophical undercurrent to these concepts, I’ve decided to use them based on the fact that they’re rather self-explanatory.
By purists, we mean traditionalists or people who have a well-defined worldview and whose values and behaviors reflect that world as closely as possible. Imagine a software developer who is a hardcore proponent of an agile or waterfall methodology, unwilling to compromise on their principles.
Pragmatists, on the other hand, are people who have a flexible worldview. They’re less interested in following a method and are more focused on the outcome. If we had to describe their core beliefs in one sentence it would be “whatever works”.
Bu reality is seldom so clean and easily defined, instead of thinking about this divide as two sides of a coin, it’s more apt to think of it in terms of a continuum. Most of us aren’t hardcore purists or pragmatists, we have a bit of both.
Some of us like the structure of methodologies, while others enjoy the freedom and creativity of a more freeform approach. Whatever the case may be, most of us are more than willing to compromise given the right context. Unfortunately, that’s not always the case, and that’s where sometimes we can find ourselves facing a dead-end.
When Methods Matter
When a friend of mine teaches their workshop, he always shares a rather funny story. When he started as a software developer, the first job he got was at a company that proudly announced that they were a 100% object-oriented development firm.
On my friend’s first project, the team was stumped because they had a problem that wasn’t easy to model with an object-oriented approach. My friend thought of a couple of solutions, both required a bit of imperative programming, but his ideas got shut down because that wasn’t part of the company’s style.
Funny as it may sound, that’s a true story, and you’d be amazed at just how common it is. It doesn’t even have to be a programming paradigm. Waterfall or agile proponents can be as rigid in their positions as this company was with its approach to software development.
There is a myriad of reasons why this happens. One explanation is the sunken cost fallacy: some companies have invested so much time and effort towards mastering a certain approach, that they find themselves applying it to everything, even if the approach wasn’t originally designed with that intention.
I tend to opt for a less cynical explanation. Human beings are creatures of tradition and habit, societies are built on the foundation of rituals. And by society, I mean from civilizations to family units, including companies.
A company’s identity is defined in part by its practices and traditions. Frameworks and methodologies provide a common language that is shared between all members, think of these as semantic shortcuts. Ways for us to quickly share information with people who share our frame of reference.
When we act outside that worldview, communication becomes more difficult, it’s harder to get the point across and we run the risk of breaking patterns or disconnecting from the community altogether.
For example, imagine a company that pushes for six-sigma, except for one department whose manager has stubbornly stuck to other forms of process improvement.
If you, as a consultor, were to check the productivity of each department, you’d have a harder time with this one department, since their approach is different from the rest it’s more difficult to assess how they are performing in comparison to others.
Going back to my friend, he may have been right, but what if they implemented the solution, and a few years down the line another team inherited the project, only to find this weird imperative piece of code in otherwise object-oriented software? For them, it might be harder to understand how the code is supposed to work.
Innovation is by its very nature disruptive, so it’s not unusual that it’s met with resistance, especially if that innovation goes against the core values or social norms of the group.
The Pragmatic Developer
Now imagine the absolute opposite, a software developer that builds their project on the basis of pure pragmatism, if it works, it goes. I’d be the first to concede that for most of us, that would be amazing, being able to write code however we wanted.
Unfortunately, that’s just not feasible. When we write code, especially for others, we have to understand that we may not be around forever. As such, our work cannot be idiosyncratic, it has to be able to communicate intent, it needs a structure that others can follow along.
Of course, once again, that’s an extreme example. Pragmatists aren’t masters of chaos, they just believe that finding the solution to a problem is more important than respecting a set of defined norms or traditions that might be constraining.
Perhaps the biggest example of pragmatic developers is those who practice hybrid methodologies, mixing the structure of the waterfall approach with the fast delivery and user involvement of agile traditions.
A common thread amongst pragmatists tends to be their level of experience. Senior developers are more prone to experimentation and less reliant on traditional approaches.
See for example how the overwhelming majority of people who work with Clojure (a Java-based functional programming language) are senior developers who are tired of working with object-oriented programming.
This is not uncommon. As Khun posits in his book about scientific revolutions, every paradigm has a limit, a point where it breaks down. That’s when the expert realizes that they need a new paradigm to solve their problem.
If structure provides a common framework, then innovation is what pushes that framework to its very limits. The alternative is rather depressing, traditionalism promotes stagnation. If we stick to our safe and reliable methods then we will reach a point where we simply can’t adapt.
And that’s the last thing we want in a business that’s accelerating by the minute.
Opposites Complement Each Other
Psychoanalyst Carl Gustav Jung understood perfectly that opposite forces aren’t counterproductive, but rather, that when they find the right balance, they enhance one another.
Pragmatism and Purism aren’t opposites, in the sense that one approach does not preclude or invalidate the other. Sticking to your methods builds structure, trying new solutions pushes your limits.
Understanding the value of each approach and promoting a culture that values both is, in my personal opinion, the best possible way to promote a flexible company with a strong core that can adapt while retaining its essence.
