agile

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

Coping With Organizational Alzheimers

Years ago, an astute manager summed up a problem that I had only vaguely intuited up to that point in my career.

Do our memories leak? Image credit: xpectro (Flickr)

“A big problem with most companies,” said Roland, “is that they have no institutional memory.”

As I recall, Roland was describing capricious political winds, and lamenting that the only form of loyalty a company has to employees is the kind they put in writing. As soon as there’s major M&A activity, or HR decides to rebalance salary allocations, or an incentive program gets adjusted to the latest management fad, all recollection of old priorities and soft obligations vanishes in a puff of smoke.

If anything, Roland was understating the problem. Companies routinely panic and change strategy half-way through an investment cycle, because they can no longer articulate the rational analysis that led them to take a plunge. Buzz floods the internet about some innovation that makes everybody excited, but we forget that we’ve heard the idea before, behind some different terminology. (Are you nodding your head because “cloud” in the last few years is just a recycling of “utility computing”from circa 2000? Trev, a colleague of mine at Adaptive Computing, showed me a dog-eared copy of The Challenge of the Computer Utility, by Douglas Parkhill. It’s all there–XaaS, elastic and on-demand, in 1966. And who knows–maybe sci-fi writers or the designers of Eniac had thought of it even before Parkhill…)

But I digress.

One particularly insidious form of forgetfulness in software relates to technical debt. Another colleague, Doug, reacted to an expedient workaround this way:

My one regret with this is that by doing something that is good enough it will never get the attention it might deserve to be made better. This happens each release: we make compromises at the very end to get it out the door, promising ourselves that we’ll revisit it later.

Folks, we don’t keep these promises to ourselves very well; Alzheimers is endemic with regards to technical debt. The only thing that saves us is that Continue reading →

Progressive Disclosure Everywhere

If you google “progressive disclosure,” you’ll get hits that describe the phrase as an interaction design technique. UI folks have long recognized that it’s better to show a simple set of options, and allow users to drill into greater detail only when they need it. (Thanks to James Russell–a brilliant UI designer–for teaching me PD years ago.)

But calling progressive disclosure a “technique” is, I think, a serious understatement. Progressive disclosure aligns with a profound cognitive principle, and its use is (and should be) pervasive, if you have eyes to see.

The Principle

Here’s my best attempt to distill the operative rule behind progressive disclosure:

Focus on essence. Elaborate on demand.

In other words, begin by addressing fundamentals without cluttering detail. When more detail is needed, find the next appropriate state, and move there. Repeat as appropriate.

Stated that way, perhaps you’ll see the pattern of progressive disclosure in lots of unexpected places. I’ve listed a few that occur to me…

Manifestations

The scientific method is an iterative process in which hypotheses gradually align to increasingly detailed observation. We learn by progressive disclosure.

Good conversationalists don’t gush forever on a topic. They throw out an observation or a tidbit, and wait to see if others are interested. If yes, they offer more info.

The development of a complex organism from a one-celled zygote, through differentiation and all subsequent phases, into adulthood, could be considered a progressive disclosure of the patterns embedded in its DNA. The recursive incorporation of the golden mean in many morphologies is another tie to biology.

A nautilus grows–progressively discloses–the protective covering it requires over its lifespan. The golden mean, repeated and repeated… Photo credit: Wikimedia Commons.

In journalism, the inverted pyramid approach to storytelling is a form of progressive disclosure. So are headlines.

Depending on how you’re reading this post, you might see a “Read more…” link that I’ve inserted right after this paragraph. Making below-the-fold reading optional is progressive disclosure at work. TLDR…

Continue reading →

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.

Example RPCD Interaction

In my last post on RPCD, I explained its key tenets. In this one, I’ll imagine one way to put it into practice.

Suppose a team is chartered to build a tool that locates birth mothers of adopted children. The team’s received some vague marching orders (“make it as easy as possible; we want to sell this as a service on facebook and the iTunes app store”). Maybe they’re using “agile” methods or even full-blown XP to guarantee that the customer’s viewpoint is represented, and that small units of work are fully processed into releasable systems on a regular basis. Or maybe they’re doing traditional waterfall, with an elaborate design phase followed by a long implementation.

Regardless, adding RPCD to this team’s behaviors might result in interactions like the following:

Step 1. Team discusses charter. They frame the charter in terms of a concrete use case. Since they don’t have a specific “real-life” customer to talk to, they postulate one. It might look like this:

Rafael just turned 18. He knows he was adopted, and he wants to find his birth mother. He knows he was born in Portland, OR on Sep 3, 1993, that his birth mother’s name was “Cindy” or “Cynthia”, and that his birth mother might have been a twin. He will interact with this product via an app on Facebook.

Step 2. Team imagines how the problem would be solved with people only, assuming that money and time is no object, and that a “white gloves” treatment is the goal. This analysis helps crystallize roles for later role play. For example:

Rafael (role = client) requests the services of a “birthmother locator” firm. The firm immediately sends an intake interviewer, Summer (role = liason) to Rafael’s home. Summer records all of Rafael’s contact info so she can interact with him in the future, clarifies Rafael’s goals, and records all information Rafael can contribute. Summer then returns to the office and arranges for Jenny (role = case mgr) to convene a group to work on Rafael’s case. The group consists of Summer and Jenny, plus Oscar (role = researcher) and Mike (role = gopher). Oscar and Mike are to begin work immediately and to report back on a daily basis. After two days, Oscar has identified 62 women whose life facts might overlap with what is known about Rafael’s birth mother. Summer contacts Rafael to report status and ask a follow-up question: does Rafael know whether his birth mother was athletic? Rafael says yes, he thinks she might have been a swimmer. Based on Rafael’s confidence in this new info, Oscar decides to narrows the search to women who appeared in high school yearbooks within +/- 5 years of 1993 and who were involved in sports. He dispatches Mike to get some HS yearbooks. He also looks in yearbooks for any girls who have a peer in the same grade, with the same last name. After three more days, Oscar has narrowed the list of candidates to two. He reports back to Summer and Jenny. Summer presents the list of candidates to Rafael and asks if he’d like them to contact the women. Rafael says no; he’ll do the final part himself. Rafael is delighted with the results and the “white gloves” treatment, and happily pays for services rendered. Summer asks him to be a reference customer, and he agrees. In fact, Rafael is so happy he can’t wait to tell all of his friends about the cool service.

Step 3. Team builds a diagram of the system, using boxes for the roles that people play. The draft a “job description” for each role.

Step 4. Team assigns roles to team members. “Fred, you’re going to pretend the client. Sally, you get to be the liason…”

Step 5. The system is deployed and goes live — in “role play” mode.

Yes, you read right. After some very early design work that can probably complete in an hour or so, the system goes into “production”. Not in its final form. Not with ultra-high standards. But in a form that allows the team to learn and refine through repeated role plays. These role plays vett the roles and the model that the team has postulated.

Role play #1 is a walk-through of exactly the scenario that the team just imagined. Fred (playing Rafael) walks to a computer, pretends to be using an app on Facebook, and says “Okay, I’m now pressing enter to submit my request.” Then Sally (playing Summer) looks at a computer screen and says, “Oh, I see that we have a new potential client. I’ll go visit him.” Already, some interesting questions should be coming to the team’s mind: Will clients be happy to be contacted by the app/service as soon as a liason like Summer is available? If so, what info should the “request help” form require so the client can be contacted? Or could a wizard automate Summer’s job? How about a chat with an online representative? Do different clients need different priorities, so that if Summer is busy when a new request arrives, she knows whether to be interrupted? Does a case manager like Jenny have to assign Summer before Summer will pay attention? The team works through these questions and continues with role play #1. Lots more questions come up as they get to the work of the researcher and the gopher. What resources will researchers have? What is the latency of getting info from those resources? How much will it cost to access those resources? Who bills the customer for expenses, and what accounting procedure must be followed? Should researchers report breakthroughs as they occur, or only once a day?

After the team works through the role play #1, it should have some intuition about which parts of the system are going to be easiest to automate. It should also have a long and ever-growing list of questions. Not all of the questions are of equal value. The team should look for ones that have major ramifications on the user experience and the scope of work, and explore those first.

Exploration takes the form of additional role plays. Since Fred was assigned the role of Rafael, his job is critical. He gets to introduce variation into the system. He shouldn’t go hog-wild all at once (“Can you bring me a pizza with your next status report?”). But he might do something like try to call his liason after a pretend hour has elapsed, to find out if any status report is available. That should cause the team some debate and head-scratching. :-) What if he asks to be notified by text in the middle of the night, no matter the hour, with new developments?

Step 6. Boundaries between automated and human components of the system are clarified. More traditional design work begins.

Step 7. The team returns to role plays whenever additional clarity is needed.

Step 8. When “the system” is delivered, it is always done as both code AND people. This means at the end of an iteration, for example, you don’t just provide a build with no bugs. You provide a role play of the system. This role play is more than a canned demo; it is an interactive demo, with people filling roles that code is not yet mature enough to handle. By viewing delivery of a “system” as delivery of a code+people ecosystem, the team is forced to consider things like how tech support will be staffed, how help will be delivered, and so forth.