manifestos

Earned Pragmatism

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.

Action Item

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?

Related articles

Manifestos

I signed two software manifestos yesterday.

photo credit: SpecialKRB (Flickr)

The Agile Manifesto is a classic. It changed the industry. Not everything about “agile” is automatically wonderful (particularly when it becomes an excuse for lazy planning), but the foundational principles are so, so true! Go. Read. Sign.

The Manifesto for Software Craftsmanship seems to deliberately emulate its predecessor’s simple and pragmatic style. I also believe deeply in its principles. I think it needs a bit more defense, however.

Steve Yegge claims that software conservatives love their code, and software liberals view code as a necessary evil. (LONG post; this comment is near the end. And you may need to read his previous post for context, if you’re not familiar with his political metaphor.)

I think he’s gone too far. I’m pretty software liberal. And I get the kernel of truth in the “necessary evil” idea. So much of what we write will be chucked or rewritten; it’s unhealthy to imagine that every project is an opportunity for a magnum opus, or to expect to be able to achieve perfection.

But I don’t think that means we should devalue the craft. Even in the imperfect, muddled, transitory universe of software, it’s possible to make savvy and artistic choices–or to do the opposite. When we care about craft, we find work more satisfying, and we make our corner of the universe a more hospitable place for our neighbors, which has all kinds of benefits.

Besides, love of craft is my major reason for blogging, so it must be a good thing, right? :-)

Action Item

Go read the manifestos. If you’re inclined, poke around for the links that let you sign.

Role-Play Centered Design

User-centered design (UCD) is important. I hope I’ve been a good advocate for it during my career. Its basic tenet is that software should be constructed as much as possible according to how users think and work, not according to techie considerations. (A seminal book on this topic is The Design of Everyday Things, by Donald Norman.) At its best, UCD promotes an alignment between technology and customer pain points that keeps software’s value proposition compelling. Even on a bad day, UCD makes software a lot more pleasant to use.

However, UCD rarely yields all potential benefits, which is why I’d like to suggest a specialized form of UCD for many software teams. I’ll dub this idea “Role-Play Centered Design” (RPCD, prounounced /ˈrɪpˌsɪd/) because of the way the various parts of the system come to life. (This idea is similar to–though conceived independently from–the concepts in this article from the proceedings of HCI ’07.)

Role plays can help you build software — not just entertain. Photo credit: TheArches (Flickr)

Manifesto

RPCD is distinguished from ordinary UCD by three key tenets.

  1. The “system” includes people.
  2. Specifics are non-negotiable.
  3. The best way to understand is to “be” the system.

Let me justify each of these ideas, and then I’ll give an example of an RPCD process at work.

The “system” includes people.

Most architectural and UML diagrams focus on software and/or hardware entities. The user’s role in the system is implicit. Even among users of activity diagrams, most workflow is computer rather than human.

This is wrong. software – people != software. Any thoughtful veteran of the industry can tell you stories about why this is so. Engineers who accept the flawed premise that only the computer side of software needs to be designed are already handicapping their UCD fatally. The system built by a software team includes people — individual users, a community, support personnel, sales folks, professional services, maintainers of docs on a web site, etc. If you let an engineer construct “the system” with no serious thought to the people, you often end up with misalignments that make it irritating to understand/use/configure/support, expensive to maintain, or even impossible to sell.

Specifics are non-negotiable.

The devil really is in the details, and if you don’t solve detailed problems, you won’t solve problems at all. The design of a system is therefore best driven by specifics–even if the specifics are only postulated. Specifics are best exemplified by use cases, and role playing forces specifics into use cases.

The best way to understand is to “be” the system.

You should “be” the software in the system, and you should “be” the people as well.

When a human being actually interviews someone in the same way an automated wizard eventually will, you learn things. The human reorders the questions or short-circuits part of the interview because she knows it’s unnecessary. Or the human gets frustrated at how needlessly cumbersome a particular part of the process is. Or the human asks some intelligent questions that you never considered. When two humans interact to model what’s eventually going to be a formal protocol, you confront asynchronicity and error handling in ways that UML or whiteboards don’t.

Modeling the system in role plays also has some other profound long-term advantages that go far beyond just what you learn. I’ll discuss these in a different post.

In my next post, I’ll give an example about how RPCD works.

Action Item

List all the people that interact with or help create your software. If your list has less than four or five unique roles, think some more. Hint: see this post.