It’s Not That Simple: The Interplay Between Fast and Slow Thinking

Our system 2 thinking observes and constantly monitors our actions and thoughts (unless it is tired or compromised). It helps regulate our behavior and to:

  • Control impulses and stop doing something that we consider inappropriate (such as eating that second piece of pie) or do something, even if we don’t like it (such as not rising to the bait in a political discussion);
  • Manage our energy, emotions, attention and behavior in socially acceptable ways to achieve our goals;
  • Stay calm, focused, and alert; and
  • Deal with daily stresses such as noise, fatigue, challenging situations or tasks, or distractions.

System 2 thinking doesn’t merely look over your shoulder to “correct” illogical system 1 thinking. The interplay between these two systems is much more complex. The two systems have deep connections and influence each other.

Emotions generated by fast thinking affect logical system 2 thinking. And fast thinking, when it doesn’t find meaningful associations that fit the current context calls upon the logical system 2 for help to interpret what is going on.

I had an opportunity to experience this interplay sitting in a bar talking with Linda Rising at an agile conference. A loud angry voice coming from the lobby abruptly interrupted our conversation. Initially, I was frightened. Then annoyed. Then irritated. (My emotional system 1 thinking kicked in). The yelling didn’t stop. Did someone need help? Why was the yelling man so upset? (Again, my system 1 was trying to connect yelling with some reason to be yelling). But I couldn’t understand what the yelling was about. And then, seemingly out of the blue (system 2 thinking coming to the rescue) I remembered that there was also a conference in the hotel on Tourette’s syndrome. That loud angry voice now made sense. It was the voice of someone with Tourette’s.

It is too simple to say that our brain is either emotional and associative (fast thinking) or logical (slow thinking).

We don’t get to choose which form of thinking we use.

The two systems interact…and that’s where it gets really interesting. Being aware of how my brain works hasn’t stopped me from being swayed by my emotions. But it has made me more aware of thinking dynamics. I may not be able to stop my knee-jerk reactions, but I am aware now that my delayed reactions and thoughts might also be helpful, if I give them enough time to surface.

On Thinking

Daniel Kahneman, in Thinking Fast and Slow, introduces two “systems” of thinking: fast or type 1, and slow or type 2. We don’t actually have two different parts to our brains—but we do have two distinct types of thinking mechanisms, each with their respective strengths and drawbacks.

Fast thinking happens automatically with little or no effort or sense of voluntary control. Quick, what’s your first reaction to this photo?

My immediate visceral reaction: “That dog is ugly! It looks crazed, angry…. scary.”

The dog is Peanut, winner of the 2014 Ugliest Dog contest. His wild hair, bulging eyes and protruding teeth are at odds with his sweet personality. Holly Chandler of Greenville, North Carolina, Peanut’s owner says he was seriously burned as a puppy, resulting in bald patches all over his body. Peanut is healthy now and nothing like my first impression.

In a nutshell, fast thinking is automatic (we do not have to work at it), impulsive (we can’t easily control it) and emotional (once I’ve told you a little about Peanut you probably feel sorry and sad and more positive towards Peanut, despite your initial reaction). Fast thinking draws on our amazing abilities to quickly form associations between related things. When it works well, we easily come to conclusions, draw out inferences, and confidently decide without breaking a sweat.

It’s sweet when your associative memory clicks along in high gear providing ready answers. But fast thinking can be subtly and easily biased. The variety of cognitive biases we have is astonishing.

In contrast, slow or system 2 type thinking requires energy. We get tired when we do a lot of slow thinking. We use slow thinking to reason logically, compute, or, surprisingly, when paying attention to someone speaking to us in a crowded noisy room. Both writing code and writing prose are slow thinking tasks for me. Reasoning about the cause of a bug is too. The fast cycles of strict TDD help some with breaking up the necessary slow thinking into more manageable chunks. For me, deciding what the test should be and how to implement my design ideas are almost always slow thinking tasks. Writing code may or may not be, depending on how familiar I am with the programming language, tool set and design context.

It is too simplistic to say that our brains are wired to be either emotional or logical. We don’t always get to choose which form of thinking we use. Even more interesting is how the two systems interact. Our system 2 constantly monitors our system 1 thoughts, and kicks in when it notices an inconsistency, saying, “Hmm…that doesn’t seem right,” perhaps leading to some conscious system 2 thinking and problem solving.

But as this two-star Amazon reviewer observes, Kahneman’s book doesn’t contain easy-to-digest pop psychology advice for how to be a better thinking being:

“Peace to all…The idea of system 1 and 2 for the brain was the twist. (System 1 is impulsive autopilot, system 2 reflective and analysis oriented)
Other than that, the book is filled with too many experiments that i felt didnt add practical value to me. I was hoping for practical solutions to help make those two systems work together in harmony…the book did NOT deliver that which was disappointing.”

Kahnman won’t fill you with sound-bite sized advice on how to sharpen your thinking. So what can you do now that you are aware of how you think? Are there ways to counteract the bad things about these systems and amplify the good things? I think so.

Since reading Kahnman, I’ve observed how my environment affects my thinking and how my thinking demands shift from task to task. Sometimes fast thinking trips me up because what I assumed made it difficult for me to really see things as they were. I keep working to counteract cognitive biases of my own and those I work with. I’ve become more aware when others don’t react as I expect or aren’t making “logical” decisions. I’ve become more understanding and less impatient.

I am experimenting with ways to support and enhance system 2 thinking in others and myself. I find that I need to carve out a space where I can work without distraction and have enough time to get deeply engaged in a challenging system 2 type task. I am easily distracted by noise or visual stimulation. I also find the Pomodoro technique doesn’t help me get more work done. I don’t have a problem with focus. My problem is knowing when to take a break. And I don’t easily get back on task after a 5 minute break.

Your experience no doubt varies. Our brains don’t work the same way. Let’s continue exploring how our daily work practices enhance our thinking and where we need to take extra care and pay more attention.

Can Nudging Help Us Make Better Choices?

Nudging, as popularized by Richard Thaler’s book Nudge, is the idea of making a by-default action the preferred choice so you don’t have to think deeply to make a good decision. However the common definition for nudge as, “a slight or gentle push or jog, especially with the elbow,” gives me reason to pause.

I don’t like being elbowed, even if it is done gently with good intentions.

Does nudging ever work?

At first glance, I was intrigued by the possibility of personally crafting my own nudges. The idea of setting up personal reminders using a service like NudgeMail, seemed promising. While potentially useful, NudgeMail reminders aren’t exactly what Richard Thaler means when he talks about nudging. A Thaler nudge is more like an unobtrusive force that moves you to make a better decision or action without feeling poked or prodded. A nudge isn’t the same as a reminder.

Successful nudges need to be unavoidable attractive shiny attractions that draw you to nearly effortlessly make good decisions or take appropriate action. They are the not prods, nags, or scoldings, either. You can’t be nudged when you are annoyed.

In today’s Oregonian there was an article about the use of electric car charging stations. The idea behind installing publicly accessible recharging stations was to “nudge” more people to buy and drive electric cars. By plunking public charging stations all over the place, the thinking went, people wouldn’t be so concerned about draining their batteries while out and about.

Public charging stations has been in failure in Oregon. Even though placed in public places, chargers are rarely used. Some appear conveniently located (like parking garages in downtown Portland). But many others are located in out of the way places (there’s one at the back end of a shopping mall near in the small town where I live. I’ve never seen a car there). Turns out they were located more as matter of political expediency than common sense or practicality.

Inconveniently, it also takes hours, not minutes, to recharge a car using them. Consequently, people find it cheaper and more convenient to plug in and recharge their cars at home overnight. They don’t need to top off their battery’s charge while working out at the gym. Often people buy electric cars with the intention of using them only for short commuter trips. They don’t need or want public charging stations.

But consider the case of Tesla. Tesla has strategically installed fast-charge station capable of delivering up to 50% battery capacity to their sporty cars in about 20 minutes (roughly 16 times faster than most public charging stations). Tesla wants its customers to feel comfortable driving their electric cars on longer trips. There’s a Tesla recharging station by the Burgerville in Centralia, Washington, halfway between Seattle and Portland. Tesla owners are more likely to travel between Portland and Seattle, a distance of 180 miles, if they can stop for a burger at the healthy, local food-sourced burger joint halfway on their journey and get their battery charged at the same time. Tesla has found the right nudge to encourage longer road trips.

The idea of painless nudges that help us “do the right thing” seems compelling. But isn’t easy to find subtle nudges for behaviors we want to change.

Merely speculating on what might be a good nudge before you implement it can be a bad idea. You need to experiment. I’m not so sure government policy-makers can or do take the time to experiment on the effectiveness of nudges before they implement them. Perhaps they should.

On a personal level, any nudge I put in place has to be cost effective, cheap to set up, and easy to tinker with. For example, buying fresh fruit (for me, anyways) is just the nudge I need to eat fruit instead of more sugary snacks. If you don’t like fresh fruit, this nudge won’t work for you.

Keeping a tab in my browser open to Duolingo, where I’m trying to learn Portuguese, is just enough of a nudge for to keep me to keep at it. I study for a few minutes every day when I need to take a break from work. And Duolingo gently sends me email reminders about keeping up my daily streak. Still relatively new to Duolingo, these reminders aren’t yet annoying. Overtime, I know they will be. I don’t like to be reminded to do what I’m already doing. I just hope they have a way to turn them off.

If motivated, I can be nudged a little. But I’ve got to be in the right mood and it has to be in an appropriate situation and context. If a nudge feels at all like a shove or a poke instead of gentle, painless, helpful guidance, I’m inclined rebel and do the opposite.

A classic example of “nudging” by policy makers is to create incentives (think tax breaks or credits). For example, giving a rebate upon buying energy efficient appliances or solar panels. That nudge has been in place for some time here in Oregon. But I haven’t bought a new energy efficient appliance simply to get a tax break. Even if the investment will be paid back in a few years in savings on my electric bill. That nudge was more likely to nudge people moving into a new home instead of someone like me.

A couple of years ago, I recycled an old refrigerator because I happened to stumble upon an extremely attractive nudge when I was searching the Internet for recycling options. I could schedule an appointment online (selecting the day and time from a list of available times) for someone to come to my house, cart away my fridge, and mail me a $50 refund check. I was in the right frame of mind for that nudge. The conveniences plus the small monetary compensation made this a perfect nudge.

But it is oh so easy to resist a nudge when I am at all forced to think even a little. I am a cranky contrarian who doesn’t like pushy nudges. Don’t tell me I have to recycle my used appliances. And don’t give me too many options to choose from, either. But give me a choice.

Nudges should be easy peasy, transparent, painless offerings of ideal options.

If you are a policy maker at your company, you might be able establish a few nudges like providing free bus passes to encourage mass transit use or putting in showers to encourage bicycling to work or exercise.

If you are an agile coach or team leader you can nudge a little, too.

Want to limit the time of a daily standup meeting? Hold it around a whiteboard and have people actually stand up. In my experience, getting comfy around a table makes meetings last longer. But watch out. I know some people who happily spend hours talking at the whiteboard. Every day. They need more than a nudge to keep stand ups brief. This leads some agile coaches to introduce protocols or standard ways of doing things that are demonstrated, and then gently enforced in order to encourage appropriate actions. How I feel about protocols and rituals is the topic for another blog post.

Nudging isn’t social engineering for social engineering’s sake, but with the intent of setting up your environment and context so you want to make the obvious better choice without feeling pressured.

Have you found effective ways to nudge yourself and change you or your team’s habits? If so, I’d like to hear from you.

Making New Behaviors Stick

My last post argued that knowing about cognitive biases and how our brain works is valuable, even if knowing isn’t enough to effectively change our behavior. Tweeter Jessica Kerr sums this up nicely, “Knowing isn’t half the battle, but without it, we don’t know the battle exists.”  Knowing doesn’t prevent  automatic behaviors and biased reactions. However, knowing gives us words we can use to reflect on our actions and feelings.

And then what? After awareness comes the really hard parts: consciously replacing undesirable, semi-automatic behaviors with more desirable ones.

Much of our daily behavior is driven by habit. Social psychologists estimate around 35-50% of our daily behaviors are driven by habit. Personally, I think that may be somewhat on the low end.

There’s a good reason for habits. If we had to consciously think through every action we took, we’d be exhausted.  When we have to consciously think about how to perform any task, it takes mental energy. And that wears us out. When we are tired we unconsciously fall back on our fast (associative) thinking to conserve mental energy and provide easy (if not always well-reasoned) answers to difficult questions.

It’s better if we can slip on our shoes in the morning and tie them without thinking.

We actively use our system 2 brain when we learn new skills or are placed into unfamiliar situations (think trying to navigate around a new neighborhood, learning customs in an unfamiliar country, learning a new problem domain or new programming language, or tracking down a tricky intermittent software bug).

When we’re not forced to work so hard, we mentally take it easy. We’re NOT lazy. But we do many things out of habit, to conserve our slow thinking, system 2 brain for when we really need it.

But what if we want to replace an old habit with a new improved one—and make that new habit automatic?

To change entrenched habits, we have to find effective replacements, insert them into our daily life…and be vigilant. This takes energy and effort.

The bad news: Old habits can still be triggered. They don’t disappear. They are simply supplanted by more recent habits (if those new habits can be successfully triggered).

One way to thwart undesirable habits is to remove their triggers from your environment. That’s why some people recommend removing unhealthy food from your household and  environment when wanting to develop healthier eating habits (easier said than done when you live with others or if there are always donuts at work on Fridays).

When it’s impractical to remove undesirable triggers, you’ve simply got to deal with them. Instead of reacting blindly to that old trigger, you can experiment with introducing new behaviors for that trigger with even stronger rewards. When the donuts show up at work, treat yourself to a good cup of coffee and slightly healthier biscotti instead (if you really really like donuts this isn’t going to work).  Better yet, avoid the strongest morning donut trigger by coming later on Friday after all the good donuts are gone (those stale donuts may be a trigger that you are still suceptible to, especially if you are tired).

This isn’t easy. Change rarely is.

Perhaps another solution to making changes stick is diligence. Be on the lookout for undesired behaviors/actions/triggers. Spot them, then quickly squelch ’em. Then go back to doing the desired behavior. This works, for a while.

Exercising diligence takes mental energy. You only have limited amounts of willpower to spare and when it is gone, well, things can get ugly. That’s why after a stressful day (when your system 2 is already tired from everything else you used it for) that you can let down your guard in a heartbeat. And then, dammit!…you slip up. You notice you slip up, beat yourself up about it, and vow to be even more vigilant. But you slip up again and…rinse, repeat….  I am not going to continue down this rat hole because it IS depressing.

So how do we get ourselves out of these mental ruts?

Evidence suggests that too much retrospection isn’t good. So don’t beat yourself up when you slip up. Recognize that you’ve slipped up  and try again. Switch things up and keep on trying (identify a better trigger or reward, experiment, try and try again). Don’t give up or give in to a defeatist attitude.

Some good news: Research suggests we are more successful at changing behaviors when we go through life changing events—when we move, retire, graduate from school, go off to college, start a new job, quit a job, marry, get ill—we are more open to change.

But I don’t wait for a big event to effect big changes. I don’t make New Year’s resolutions, either. Instead, I periodically mix things up and try new things just for their novelty. Life is a grand experiment.

But still…research hasn’t yet shown how to sustain new behaviors. Even years after embracing new behaviors, we are prone to slipping up, given the right triggers (think vacations, travel, holidays).

Knowing how we can slip-up is not enough to avoid slip-ups. Santos and Gendler are right.

But believing that you can recover after a slip up is key to getting back on track. And that’s where a positive mindset, determination, the belief that you can learn from mistakes, and resilience go a long way towards making change and making changes stick.

Footnote: The Power of Habit by Charles Duhigg is a good book for those wanting to know more about habits in their life and business.

What good is knowing if it’s not half the battle?

Cognitive psychologists Laurie Santos and Tamar Gendler answered Edge.org’s 2014 question of the year, “What scientific idea is ready for retirement?” by stating we should retire our unquestioned belief that, “Knowing is half the battle.” The phrase, “knowing is half the battle” was popularized by the 1980s G.I. Joe cartoon’s ending message, “Now you know. And knowing is half the battle.”

I am too old to have watched G.I. Joe cartoons…but somehow that meme worked into my brain and has colored my outlook on life. I’m always seeking new information. I want to know and then act based on that knowledge.

Santos and Gendler state that, “Recent work in cognitive science has demonstrated that knowing is a shockingly tiny portion of the battle for most real world decisions.” When it comes to making decisions, knowing about how our brains work isn’t enough to stop us from making irrational decisions, doing things in the short term that undermine our long-term goals, or being biased by seemingly incidental (and unimportant) information. In fact, knowing might even get in the way of taking appropriate action.

But I like to know how things work. I want to believe that if I knew more about how my brain works, that I could make better decisions, act more rationally, and be less influenced by my goofy cognitive biases.

Yet, when I read Santos’ and Gendler’s Edge response and dug into their research, I realized that I have been deluding myself. Knowing is rarely sufficient to overcome our “built-in” brain reactions.

Knowing isn’t intrinsically bad. It just isn’t sufficient to effect change. Yet I still want to know how things work. I still believe knowing is incredibly powerful.

So what good is knowing?

Knowing a name for some thing gives you the vocabulary to talk about it. In my review of Design Patterns, I said, “most importantly, it names these design constructs, allowing teams to share a common vocabulary.”

You aren’t a better designer because you know design patterns. There is so much more to design than knowing a few patterns or applying them to solve a problem. But knowing about patterns enables you to have more informed conversations about what you see in existing designs and what design possibilities there are.

Knowing about system 1 and system 2 thinking as described in Kahneman’s, Thinking Fast and Slow, and how they interact can help you talk about how you behaved the way you did.

Knowing about a thing or concept enables you to see it. Once I knew of the Cargill logo, I spotted it everywhere. On trains, buildings, products. Before that, it was invisible.

Knowing about cognitive biases can help you spot “irrational” decisions.

Knowing about some thing helps you focus attention on it (which can at times be good). But simply increasing awareness and attention won’t guarantee that you won’t miss something else important or avoid making poor decisions.

Simply knowing isn’t enough to eliminate undesirable associations or remove biases. Otherwise, you’d never have knee-jerk reactions and would always accurately weigh risks and rewards when making an important decision.

We can’t change our “system 1” thinking with its automatic fast associations. That’s how we’re wired. Associations are freewheeling, making us extremely susceptible to priming, anchoring, and myriad other cognitive biases.

Knowing increases awareness. Maybe I’m overly optimistic, but I believe increased awareness is the first step towards making any significant change.

Knowing doesn’t prevent the triggering automatic behaviors and reactions. But it helps us shape the words we can use to reflect on our actions and feelings. And then, what?

If we want to behave differently, we need to take some action to avoid tripping up in the future. But since we can’t turn off our automatic reactions, what can we do? Indeed, changing “automatic” reactions is hard.

And that’s the focus of my next blog post.

Beware of Dogma. No. Be aware of dogma

Dogma has several different meanings. I’m going to purposefully split hairs in this post, because I don’t want to attach negative connotations to dogma in a knee jerk fashion. I want to be more thoughtful about my choice of words and my reactions to them.

Here are four meanings for dogma:

“1. an official system of principles or tenets concerning faith, morals, behavior, etc., as of a church.
2. a specific tenet or doctrine authoritatively laid down.
3. prescribed doctrine proclaimed as unquestionably true by a particular group.
4. a settled or established opinion, belief, or principle”
from dictionary.com

At first, these subtle differences in meanings annoyed me. But I wanted to push through that to see what I can learn about dogma. So here goes…

An official set of principles or tenets concerning faith, morals and behavior.
As a software professional, do I have an “official” set of principles and tenets that I believe in?

I have a set of guiding principles and practices for how I work, think about design, write code and tests that I’ve built up over 20+ years of practice. They have become part of how I prefer to operate. I’ve changed and refined them over time, discarding some practices, fine tuning others.

The guiding principles I follow weren’t handed down by authorities. I discovered them working alongside smart people and interacting with thoughtful designers who cared deeply about how they built and implemented software. I wanted to understand how productive people thought and worked, and try to incorporate what I saw as good practices and beliefs into my own beliefs and ways of working.

In the process, I co-wrote two object design books that shared a way of thinking about objects that I still find effective and powerful. Maybe writing books made me an authority. But I also have become a seeker of new and better ways of working. Over the years I have “blended” into my personal set of practices and beliefs about design some powerful ideas of others. This process of incorporating these ways of thinking and problem solving to me feels highly integrative rather than just “accepting” them as unchallenged beliefs or tenets. I have to sort through them, adjust them and then make them part of who I am and what I do. I am not one to blindly accept dogma.

The 3rd definition of dogma has negative connotations: a prescribed doctrine proclaimed as unquestionably true by a particular group.

Hm. I don’t hold many things about software design as being unquestionably true. I find it disconcerting when groups and factions form around the latest truth or discovery. For example, some fervent agile developers I know unquestionably believe that test-first development is the only way to design software. (I’m more of a test-frequent designer by nature). Those who refuse to acknowledge that there are other effective pathways to producing well-written, well-designed, maintainable code are trying to push a dogma of the 3rd meaning.

I find myself questioning any software doctrine that is held as being “universally” true. How presumptuous! There are so many different ways to solve problems and build great software.

I try to keep an open mind. My most strongly held beliefs are ones I should challenge from time to time. To do that, I have to push myself out of my comfort zone. For example, I have discovered a few things by letting go of several strongly held beliefs and performing some interesting experiments: How much code that checks expected behaviors do I really need to keep around to keep software from regressing? How many tests does any organization really need to keep? How many comments do I need in my code? How much of my code should check for well-formed arguments? Is it better to fail fast or fail last? What’s the effect on my code to put in all those checks? What’s the effect of leaving them out.

Not all dogma is handed down from on high or authoritatively laid down…nor is it necessarily bad to hold a common set of beliefs and opinions (the fourth definition of dogma). I’ve been in dysfunctional groups where we couldn’t agree on anything. It was extremely stressful and unproductive.

If as a group we establish and hold a common set of beliefs and practices, then we can just get on with our jobs without all that friction jockeying for who is right and the right way to do things.

But, here’s the rub…if you accept a certain amount of dogma (and I’m not saying what kind of dogma that might be…if you are an agile software developer I am sure you hold certain beliefs on testing, task estimation, collaboration, specification, keeping your code clean, whatever…) be wary of becoming complacent. Dogma needs to be challenged and re-examined from time to time. But don’t toss your current dogma aside on a whim, either. Old beliefs can get stale. But they may still be valid. We need to try out new ideas. But not simply discard older beliefs because shiny new ones are there to distract us.

What Makes for Lively Centers?

In this blog I dig a bit deeper into what makes good, lively centers.

Let me introduce another property of lively centers: alternating repetition. Consider this photo I took of blooming plum trees in Kyoto.

The photo doesn’t do the scene justice. The flowering trees went on and on and on.

And on.

Forking off the thick trunks were ever thinner arching mossy green and dark branches covered with blossoms. Those blossoms seemed to float between branches forming a sea of pink. I could get lost in those trees.

Looking out over that landscape I felt peaceful, relaxed, and calm.

Earlier, walking the streets of Kyoto I snapped this photo (imagining the sign was inviting me to get with it, “chill out”, be calm and come inside to purchase whatever they were offering).

That sign made me laugh. It contrasts the difference between strong centers that reach out and grab me with the rather flat-affect of everyday more mundane centers. The sign made me curious, but not enough to go inside the shop.

Good alternating repetition doesn’t mean the same thing over and over again. It involves smaller sub-patterns of repeating structures. In preparing for our workshop on Alexander’s properties, I looked for an example of alternating repetition in my personal life. I jog. So it was easy to find alternating repetition in my running routine (Joe Yoder found it in his dancing).

I jog several times a week. I don’t do the same routine everyday. Once a week, typically on Thursdays, I do tempo training with my running coach. She makes me run harder than I’d like to normally do for either a specific distance or time, then has me run easily for a bit to recover. I repeat this hard run-easy jog recovery cycle 3 or 4 times a session. Other days I do my normal easy 3+ mile runs (outside when the weather permits) through town. On the weekends I do a longer run of an hour or more at a comfortable pace. I repeat this cycle each week, with variations due to the running season (winter is slower/less running than summertime) or whether I am recovering from an injury or getting back to running after traveling or recovering from a race.

Another property of strong centers is local symmetry. The photo of these shrines (again, taken in Kyoto) illustrates this.

The shapes of the rooflines, windows, and pedestals are similar, not identical. Slight variations make them more interesting.

Here is the welcoming Port wine and strawberry arrangement that my husband and I found in our Doro valley hotel room in Portugal.

Symmetrical. But berries are closer together on the right hand plate. The napkin folds differ. Perfect symmetry is less pleasing (at least to me) than near symmetry. Alexander claims that a hand-hewn quality strengthens centers (he calls this property “roughness”).

When I discover a strong system of centers I get an emotional kick. And there it is. You discover Alexander’s properties when you engage with the things in your life and form personal connections (rather than letting the scene just float by). Finding Alexander’s properties involves a bit of luck, developing a discriminating eye, and being on the alert for positive connections between what you are experiencing and/or making.

Making strong, lively centers is another matter altogether. Yet how hard can it be? Well…that is a topic for another blog post or two.

Can’t I Just Be Reasonable?

“Don’t it always seem to go
That you don’t know what you’ve got
Till it’s gone” –Joni Mitchell, Big Yellow Taxi

My husband “loaned” my unused iPad to my father-in-law. I hadn’t used it in a year. He thought since it might expand his dad’s horizons and bring the Internet to him for the first time. But my father-in-law didn’t use the iPad either. Upon finding it stashed in a drawer with its power drained (after a couple of months), I demanded it back.

I proceeded to load it with some New Yorkers to read on a trip.

It was great…for a very short while.

But this past week I read a physical New Yorker instead of its e cousin. There was something extremely satisfying about shuffling and folding its pages. Sure, I can listen to poets read their poems and enjoy the extra photos on my iPad. But the video clips? Not that interesting.

My iPad remains underutilized. And I am feeling a bit guilty about asking for it back. Why did I want it back? Why did I react so strongly to “losing” my unused iPad?

Daniel Kahneman, in Thinking Fast and Slow, gives insights into how we react to perceived gains and losses. We respond to a loss far more strongly than we do to an equivalent gain. Take something away and we’ll pine for it even more than its perceived value. And we are driven more strongly to avoid losses than to achieve gains. No, that isn’t rational. But it’s how we are wired.

Sigh. So chalk up my reaction to my loaned iPad to petty possessiveness and an ingrained reaction to perceived loss.

Even more distressing, Kahneman points out that we take on extra risks when faced with a loss. We continue to press on in spite of mounting losses. Losing gamblers keep gambling. Homeowners are reluctant to sell a house that is underwater in value and move on. And additional time and resources get allocated to late, troubled software projects with little or no hope for success. It’s easier than deciding to pull the plug.

Not surprisingly, our aversion to loss increases as the stakes increase. But not dramatically. Only when things get really, really bad do we finally do pull back and stop taking avoidable risks. And to top that off, loaded, emotional words heighten our perception of risk (conjuring up scary imaginary risks that we then don’t react to rationally).

So knowing these things, how can I become a better decision-maker? Right now, I don’t see any easy fixes. Awareness is a first positive step. When I feel a pang of loss I’m going to try to dig deeper to see whether I need to shift my perspective (which might be hard to do in the heat of the moment, but nonetheless…). Especially when I suddenly become aware of a loss. Knowing about loaded, emotional words, I’m going to be sensitive to any emotional “negative talk” that could distort my perceptions of actual risks.

Still, I’m searching for more concrete actions to take that can help me react more rationally to perceived losses. Is this a hopeless cause? I’m interested in your thoughts.

Distinguishing between testing and checking

At Agile 2013 Matt Heusser presented a history of how agile testing ideas have evolved in “Twelve Years of Agile Testing: And What Do We Do Now?” The most intellectually challenging idea I came away from Matt’s talk was the notion that testing and checking are different. I’m still trying to wrap my head around this distinction.

Disclosure: I’m not a testing insider. However, along with effective design and architecture practices, pragmatic testing is a passion of mine. I have presented talks at Agile with my colleague Joe Yoder on pragmatic test driven design and quality scenarios.

Like most, I suspect, I have a hard time teasing out a meaningful distinction between checking and testing. When I looked up definitions for testing and checking there was significant overlap. Consider these two definitions:

Testing-the means by which the presence, quality, or genuineness of anything is determined

Testing-a particular process or method for trying or assessing.

And these for checking:

Checking-to investigate or verify as to correctness.

Checking-to make an inquiry into, search through, etc.

Using the first definition for testing, I can say, “By testing I determine what my software does.” For example, a test can determine the amount of interest calculated for a late payment or the number of transactions that are processed in an hour. Using the second meaning of testing, I can say that, “I perform unit testing by following the test first cycle of classic TDD” or that, “I write my test code to verify my class’ behavior after I’ve completed a first cut implementation that compiles.” Both are particular testing processes or methods.

I can say, “I check that my software correctly behaves according to some standard or specification (first meaning).” I can also perform a check (using the second definition) by writing code that measure how many transactions can be performed within a time period.

I can check my software by performing manual procedures and observing results.

I can check my software by writing test code and creating an automated test suite.

I might want to assess how my software works without necessarily verifying its correctness. When tests (or evaluations) are compared against a standard of expected behavior they also are checks. Testing is in some sense a larger concept or category that encompasses checking.

Confused by all this word play? I hope not.

Humans (and speakers of any native language) explore the dimensions and extent of categories by observing and learning from concrete examples. One thing that distinguishes a native speaker from a non-native speaker is that she knows the difference between similar categories, and uses the appropriate concept in context. To non-native speakers the edges and boundaries of categories seem arbitrary and unfathomable (meanings aren’t found by merely reading dictionary definitions).

I’ve been reading about categories and their nuances in Douglas Hofstadter and Emmanuel Sander’s Surfaces and Essences. (Just yesterday I read about subtle difference between the phrases, “Letting the cat out of the bag” and “Spilling the beans.”)

So what’s the big deal about making a distinction between testing and checking?

Matt pointed us to Michael Bolton’s blog entry, Testing vs. Checking. Along with James Bach, Michael has nudged the testing world to distinguish between automated “checks” that verify expected behaviors versus “testing” activities that require human guided investigation and intellect and aren’t automatable.

In James Bach’s blog, Testing and Checking Refined, they makee these distinctions:

“Testing is the process of evaluating a product by learning about it through experimentation, which includes to some degree: questioning, study, modeling, observation and inference.
(A test is an instance of testing.)

Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product.
(A check is an instance of checking.)”

My first reaction was to throw up my hands and shout “Enough!” My reaction was that of a non-native speaker trying to understand a foreign idiom! But then I calmed down, let go of my urge to precisely know James and Michael’s meanings, accept some ambiguity, and looked for deeper insight.

When Michael explained,

“Checking is something that we do with the motivation of confirming existing beliefs” while, “Testing is something that we do with the motivation of finding new information.”

it suddenly became more clear. We might be doing what appears to be the same activity (writing code to probe our software), but if our intentions are different, we could either be checking or testing.

Why is this important?

The first time I write test code and execute it I learn something new (I also might confirm my expectations). When I repeatedly run that test code as part of a test suite, I am checking that my software continues to work as expected. I’m not really learning anything new. Still, it can be valuable to keep performing those checks. Especially when the code base is rapidly changing.

But I only need to execute checks repeated on code that has the potential to break. If my code is stable (and unchanging), perhaps I should question the value of (and false confidence gained by) repeatedly executing the same tired old automated tests. Maybe I should write new tests to probe even more corners of my software.

And if tests frequently break (even though the software is still working), perhaps I need to readjust my checks. I’m betting I’ll find test code that verifies details that should be hidden/aren’t really essential to my software’s behavior. Writing good checks that don’t break so easily makes it easier to change my software design. And that enables me to evolve my software with greater ease.

When test code becomes stale, it is precisely because it isn’t buying any new information. It might even be holding me back.

I have a long way to go to become a fluent native testing speaker. And I wish that James and Michael could have chosen different phrases to describe these two categories of “testing” (perhaps exploration and verification?).

But they didn’t.
Fair enough.

Evangelizing New (Software Architecture) Ideas and Practices

Last December I spoke at the YOW Conferences in Australia on Why We Need Architects (and Architecture) on Agile Projects.

I wanted convince agile developers that emergent design doesn’t guarantee good software architecture. And often, you need to pay extra attention to architecture, especially if you are working on a large project.

There can be many reasons for paying attention to architecture: Meaningful progress may be blocked by architectural flaws. Some intricate tricky technical stuff may need to be worked out before you can implement functionality that relies on it. Critical components outside your control may need to be integrated. Achieving performance targets may be difficult and you need to explore what you can do before choosing among expensive or hard to reverse alternatives. Many other developers may depend on some new technical bit working well (whether it be infrastructure, that particular NoSQL database, or that unproven framework). Some design conventions need to be established before a large number of developers start whacking away at gobs of user stories.

I characterized the role of an agile architect as being hands-on; a steward of sustainable development, and someone who balances technical concerns with other perspectives. One difference between large agile and small agile projects is that you often need to do more significant wayfinding and architectural risk mitigation on larger projects.

I hoped to inspire agile developers to care more about sustainable architecture and to consider picking up some more architecture practices.

Unfortunately, my talk sorely disappointed a thoughtful architect who faces an entirely different dilemma: He needs to convince non-agile architects to adapt agile architectural practices. And my talk didn’t give him any arguments that would persuade them.

My first reaction to his rant was to want to shout: Give up! It is impossible to convince anyone to adopt new way of working that conflict with his or her deeply held values.

But then again, how do new ways of working ever take hold in an organization? By having some buzz around them. By being brought in (naively or conscientiously) by leaders and instigators who know how to build organizational support for new ideas. By being new and sexy instead of dull and boring. By demonstrating results. By capturing people’s imagination or assuaging their fears. Surreptitiously, quietly replacing older practices when reasons for doing them are no longer remembered. When the old guard dies out or gives up.

Attitudes rarely change through compelling discussions or persuasive argumentation. I look to Mary Lynn Manns and Linda Rising’s Fearless Change: Patterns for Introducing New Ideas for inspiration.

I take stock of how much energy I want to invest in changing attitudes and how much investment people have in the way they are doing things now. I don’t think of myself as a professional change agent. Yet, as a consultant I am often brought in when organizations (not necessarily every person, mind you) want to do things differently.
People generally aren’t receptive to new ideas or practices or technologies when they feel threatened, dismissed, disrespected, underappreciated, or misunderstood. I am successful at introducing new techniques when they are presented as ways to reduce or manage risks or increase productivity or reliability or improve performance or whatever hot button the people who I am exposing these new ways of working are receptive to. Labeling techniques as “agile” or “lean” may create a buzz in those that already receptive. But the reaction can be almost allergic in those who are not. The last thing I want do is to foster divisiveness. Labels do that. If I get people comfortable taking just that next small step, that is often enough for them to carry on and make even more significant changes. Changing practices takes patience and persistence. At the end of the day I can only convince, demonstrate and empathize; I cannot compel people to make changes.