The other day I was on Gene Hughson’s blog (he’s a smart guy, btw; I recommend a visit), and I noticed a badge that said that he had signed “The Oath of Non-Allegiance.”
That piqued my curiosity.
I followed Gene’s link and ended up on Alistair Cockburn’s website. Alistair is one of the early torchbearers for the agile software movement. I’ve written previously about signing the Agile manifesto, so I felt like I was swimming in friendly waters.
The oath is about being open-minded and pragmatic:
I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.
In other words, let’s examine ideas on their merit, rather than dismissing them because they don’t align with the programming or process or architecture or platform buzzword du jour.
I signed. Good stuff.
However, the oath got me thinking a bit, and I want to register two notes of caution.
Caution 1: It is possible to be too pragmatic.
On the continuum that has “ivory-tower idealism” at one end, and “pragmatism” at the other, I’m well past center, favoring the pragmatic side. However, we should not discount the value of idealism. It was pragmatists who found enough compromise to ratify a constitution that made a loose confederacy into the United States of America–but it was the firebrand idealism of folks like Thomas Paine that articulated a vision, inspired a previously fragmented public, and provided the heat to carry the revolution through its darkest winters.
You need both.
I have seen architects that are way too ivory-tower. They make recommendations based on their favorite patterns and methodologies, with little regard for practical consequences. Smart engineers quickly dismiss them as being out of touch and irrelevant, and they are right to do so.
On the other hand, I have seen “architects” who, despite deep talent as engineers, are forever in the mode of “whatever gets the job done” and “if it ain’t broke, don’t fix it.” I believe this view is short-sighted; it loses touch with the opportunity cost of sub-optimal decisions, and with the human passion that keeps architectures healthy. Codebases owned by this type of “architect” tend to be rife with tech debt, with no roadmap or process to haul the team up and out. Where there is no vision, the people perish.
Caution 2: Pragmatism must be earned.
Before you can be a pragmatist, you have to understand what’s possible, what’s good and bad about each alternative, and why certain considerations might trump others given a certain business context and time horizon. This perspective doesn’t come cheap; it’s been my experience that only the school of hard knocks teaches these classes, and the tuition is expensive.
I mistrust anyone who lightly dismisses OO or message passing or actors or whatever the technique is, on the basis of shallow prejudice–but I also mistrust anyone who picks and chooses from the smorgasbord based purely on convenience of the moment. As Oliver Wendell Holmes said, “I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.” Unless you truly wrestle with the complexity, pragmatism can degenerate into cheating and chaos. Or said another way: only seasoned idealists earn the right to be pragmatists.
Consider where you fall on the idealism~pragmatism continuum. Advocate the opposite end of the spectrum with yourself in a mental debate; do you have anything to learn from those who position themselves differently?
- 4 Agile Teams to Avoid (agile.dzone.com)
- Rorty’s Consequences of Pragmatism (matthewkr.com)
- 10 Skills All IT Architects Should Have (news.dice.com)
- Brief History of Agile Movement (offshore-agile.com)
- A tale of a 7 year journey in developing software for the enterprise (theenterprisearchitect.eu)
- Introduction To Agile Principles (javacodegeeks.com)
15 thoughts on “Earned Pragmatism”
First of all, I have to say “thank you” for the compliments. I don’t expect to see those pop up in the feeds I subscribe to – it was a pleasant surprise.
Regarding your follow up points, I definitely agree. I put pragmatism in the center of a continuum that starts with dogma on one end and anarchy on the other. Drifting aimlessly is no better than following blindly. Your second point illustrates the cure to the first – being able to justify your decisions should help to keep you from swinging too far to either side.
Thanks again, and great post!
Gene: thanks for some great content on your own blog, and for pointing me to the oath. Good learning all around!
One thing I’ve noticed is that in my experience, my own willingness to burn the midnight oil can make up for the occasional drift too far into the realm of the idealist. I may look at a functional code base with some technical debt that’s not hurting the business and experience a kind of OCD “we can make this better.” If I solve this on the company dime, that’s no good, but if I go home with the challenge, prove it out, implement it and present it, it’s a win for everyone — company gets less tech debt for free and I learn something in the process while satisfying my own neurosis.
Long story short — a way to bridge the idealist-pragmatist gap is to indulge idealism when nothing is at stake.
Erik: Thank you for a very insightful observation! You’ve put into words something that I intuited but could never quite articulate–why it’s vital that architects tinker and write code on their own time. This is one example of a perfect compromise where everybody comes out ahead.
I think the most important sentence you wrote was:
“You need both.”
I find my movement along the continuum is based on the task at hand. There’s a time to push for the ivory-tower ideal and other times when doing anything more then the “quick and dirty” is overkill. The trick, and it’s a difficult trick to pull off consistently, is to know the difference. I have no lack of examples where what I thought was the best approach turned out to be diametrically opposed to what would have been best. I think that’s where experience is king and dogma is the enemy, as I’ve seen too many push too far into the area of diminishing returns (e.g., we *must* handle every use case–even the one that only occurs once every billion years) and too many dash off something quick that eventually becomes a millstone around the organization’s neck.
I guess we could get into a discussion of eastern philosophy at this point….
I’m chuckling about the “eastern philosophy” comment. Did you connect to that worldview while in Japan–or earlier?
I also have lots of examples where I haven’t struck the balance wisely. Sigh…
Earlier. My family has long had a connection with the Orient (Asia particularly). 中庸, or the Golden Mean, was at times brought up in home discussions while growing up.