Should you adopt a methodology or focus on problem solving? Are these approaches at odds, or can there be common ground?
The history of the human debate over the value of tradition versus progress is as old as Western civilization itself. Every field of human endeavor, from philosophy to science, has seen the clash between purists and pragmatists struggling to decide which approach is more reliable.
Ironically, not even the business world, a social environment known for its very pragmatic worldview, is immune to this debate. Software developers, managers, and data scientists have, at one time or another, experienced tension between those who promote one methodology or style and those who tend to prefer an eclectic approach.
Understanding the debate
I have decided to use the terms Purist and Pragmatist to refer to each side of this debate. There is no philosophical bent to these concepts, I decided to use them based on the fact that they are quite 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 staunch supporter of an agile or waterfall methodology, unwilling to compromise his principles.
Pragmatists, on the other hand, are people who have a flexible worldview. They are less interested in following a method and more focused on the result. If we had to describe your core beliefs in one sentence, it would be “whatever works.”
But reality is rarely so clear and easily defined, rather than thinking of this division as two sides of a coin, it is more likely to think of it in terms of a continuum. Most of us are not radical purists or pragmatists, we have a little of both.
Some of us like the structure of methodologies, while others like the freedom and creativity of a freer approach. Whatever the case, most of us are more than willing to compromise in the right context. Unfortunately, this is not always the case, and this is where we can sometimes find ourselves facing a dead end.
When methods matter
When a friend of mine teaches at his workshop, he always tells a very funny story. When he started out as a software developer, the first job he got was at a company that proudly advertised that it was a 100% object-oriented development company.
In 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 few solutions, both requiring a bit of imperative programming, but his ideas were shut down because it wasn't the company's style.
As funny as it may sound, this is a true story, and you'd be surprised how common it is. It doesn't even have to be a programming paradigm. Proponents of waterfall or agile can be as rigid in their positions as this company was with its approach to software development.
There are a multitude of reasons why this happens. One explanation is the sunk cost fallacy: some companies have invested so much time and effort into mastering a particular approach that they end up 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 rituals. And by society I mean everything from civilizations to family units, including businesses.
A company's identity is defined in part by its practices and traditions. Frameworks and methodologies provide a common language that is shared among all members, think of them as semantic shortcuts. Ways we can quickly share information with people who share our frame of reference.
When we act outside of this worldview, communication becomes more difficult, it is more difficult to convey the idea and we run the risk of breaking standards or completely disconnecting from the community.
For example, imagine a company that seeks six sigma, with the exception of a department whose manager stubbornly adheres to other forms of process improvement.
If you, as a consultant, were to check the productivity of each department, you would have more difficulty with this department, as its approach is different from the others, it is more difficult to evaluate its performance in comparison to the others.
Going back to my friend, he may be right, but what if they implemented the solution, and a few years later another team inherited the project, only to find this strange imperative piece of code in object-oriented software? For them, it may be more difficult to understand how the code should work.
Innovation is, by nature, disruptive, so it is not uncommon for it to encounter resistance, especially if that innovation goes against the group's core values or social norms.
The pragmatic developer
Now imagine the absolute opposite, a software developer who builds his project on the basis of pure pragmatism, if it works, it goes. I would be the first to admit that for most of us, it would be awesome to be able to write code any way we wanted.
Unfortunately, this is simply not feasible. When we write code, especially for others, we have to understand that we may not exist forever. As such, our work cannot be idiosyncratic, it needs to be able to communicate intent, it needs a structure that others can follow.
Of course, once again, this is an extreme example. Pragmatists are not masters of chaos, they just believe that finding a solution to a problem is more important than respecting a set of defined norms or traditions that can be restrictive.
Perhaps the greatest example of pragmatic developers are those who practice hybrid methodologies, mixing the structure of the waterfall approach with the rapid delivery and user involvement of agile traditions.
A common trait among pragmatists tends to be their level of experience. Senior developers are more prone to experimentation and less dependent on traditional approaches.
See for example how the overwhelming majority of people working with Clojure (a functional programming language based on Java) are senior developers who are tired of working with object-oriented programming.
This is not uncommon. As Khun postulates in his book on scientific revolutions, each paradigm has a limit, a point where it disintegrates. That's when the specialist realizes that he needs a new paradigm to solve his problem.
If structure provides a common framework, then innovation is what pushes that framework to its limits. The alternative is quite depressing, traditionalism promotes stagnation. If we stay true to our safe and reliable methods, we will reach a point where we simply cannot 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 perfectly understood that opposing forces are not counterproductive, but rather that, when they find the right balance, they enhance each other.
Pragmatism and Purism are not opposites, in the sense that one approach does not exclude or invalidate the other. Following your methods creates 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 adapts but maintains its essence.
