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













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.


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








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

Cognitive psychologists Laurie Santos and Tamar Gendler answered’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”

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.

Why Process Matters

I’ve been working on a talk for Smalltalks 2014 about Discovering Alexander’s Properties in Your Code and Life.

I don’t want it to be an esoteric review of Alexander’s properties.

That won’t satisfy my audience or me.

I want to impart information about how Alexander’s physical properties might translate to properties of our software code as well as illustrate poignant personal examples in the physical world.

But equally important, I want impress upon my audience that process is vital to making lively things (software and physical things). In his, The Process of Creating Life: Nature of Order, Book 2, Alexander states,

“Processes play a more fundamental role in determining the life or death of the building than does the ‘design’.”

Traditionally, building architects hand off their designs as a set of formal drawings for others others to build. Does this remind you of waterfall software development? There isn’t anything inherently wrong with constructing formal architectural drawings…but they never end up reflecting accurately what was built. Due to errors in design, situational decisions based on new discoveries made as things are built, better construction techniques, changing requirements, limitations in tools or materials, a building is never exactly constructed as an architect draws it up.

Builders know that. Good ones exercise their judgment as they make on the spot tactical re-design decisions. Architects who are deeply involved in the building process know that.

Alexander is rather unhappy with how buildings are typically created and suggests that any “living” process (whether it be for building design or software or any other complex process) incorporate the following ten characteristics.

He challenges us software makers to do better, too:


As software designers and implementers we know that nothing is ever built exactly as initially conceived. Not even close. Over the past decade or so we have made significant strides our processes and our tools that enable us to be more effective at adaptively and incrementally building software. My thoughts on some ways we have tackled these characteristics are interspersed in italics, below.

Characteristics of Living Processes

1.Step-by-step adaptive. Small increments with opportunity for feedback and correction.
Incremental delivery, retrospectives, stakeholder reviews
Repetitive incremental design cycles:
Design a little– implement–refactor rework refine–design…
Design/test cycles: Write specifications of behavior, write some code that correctly works according to the specification, test and adapt…
Tests and production code equally valued

2. Whatever the greater whole is always the main focus of attention and the driving force.
Working deployable software, minimally-marketable features

3. The entire process is governed and guided by the formation of living centers (that help each other)
Code with defined boundaries, separate responsibilities, and planned for interconnections

4. Steps take place in a specific sequence to control the unfolding.
We have a rhythm to our work. Whether it is test-first or test-frequent development, conversations with customers to define behavioral “specifications”, or other specific actions. In order to control unfolding we need to understand what we need to build, build it, then refine as we go. And we have tools that let us manage and incrementally build and record our changes.

5. Parts created must become locally unique.
Build the next thing so it fits with and expands the wholeness of what we are building. Consider our options. Refactor and rework our design. Make functions/classes/code cohesive. Bust up things that are too big into smaller elements. Revise.

6. The formation of generic centers is guided by patterns.
We have in mind a high-level software architecture that guides our design and implementation.

7. Congruent with feeling and governed by feeling.
Instead of just making a test pass, see if what you just wrote feels right (or if it feels like an ugly hack). Reflect on how and what we are building. Don’t be merely satisfied with making your code work. How do you feel about what you’ve just built? How do those using your software react to it? How do those who have to maintain and live with your code feel about it?

8. For buildings, the formation of structure is guided by the emergence of an aperiodic grid, which brings coherent geometric order
Software is structured, too…we’ve got to be aware of how we are structuring our code.

9.Oriented by a form language that provides concrete methods of implemented adapted structure through simple combinatory rules
We use accepted “schemas” to create coherent software systems. We have software architecture styles, framework support, and even pattern languages emerging…

10. Oriented by the simplicity transformation, and is pruned steadily
We can consistently refactor and rework our code with the goal of simplifying in order to enable building more functionality. We rebuild to create sustainable software structures. Even if we come back to some old working code and see how to simplify it, we can rework it taking into consideration what we’ve learned in the meantime.

Yet, let’s not be complacent. Agile or Lean or Clean Code or Scrum practices don’t address every process characteristic Alexander mentions. I am not sure that all these characteristics are important for building lively software. Alexander is not a builder of software systems, although he spent a lot of time talking with some pioneers and leaders of the software patterns movement.

Some process ideas of Alexander sound expensive and time consuming. Do we always need to reflect on how we feel about what we code? Sometimes we need to build quickly, not painstakingly. We need to prove its worth, and then refine our software. Our main thought may be on just simply making it work, not how it makes us or others feel. So how do we add liveliness to this quickly fashioned software? What’s a good process for that? Mike Feathers wrote about Working Effectively With Legacy Code, but there is a lot more to consider. Maybe that quickly fashioned software has tests, maybe it doesn’t, maybe some parts have a reasonable structure, and maybe other parts should be tossed.

We often build disposable and hopefully short-lived software. Problems crop up when that code gets rudely hacked to extend its capabilities and live past its expiration date.

There are most likely different processes for creating lively software, based on where you start, where you think you are headed, and how lively it needs to be (not everything needs to be fashioned with such care).

People are continually building new and better tools and libraries. There is a rich and growing ecosystem of innovative open source software. Process matters. I think we have a lot still to learn about building lively software. It is a heady time to be building complex software systems.

When in Rome…

I attended my first XP conference in Rome in May. As they say, “when in Rome, do as the Romans do.” The actual quote attributed to St. Ambrose is, “si fueris Romae, Romano vivito more; si fueris alibi, vivito sicut ib,” or “if you should be in Rome, live in the Roman manner; if you should be elsewhere, live as they do there.”

As Italians do, I enjoyed good food, good company, and great wine.

I gave a workshop on Understanding Design Complexity (using commonality-variability analysis) and a tutorial on Agile Architecture Values and Practices.

I also sampled research AND non-research sessions in equal measure. Unlike other agile conferences I’ve attended, research is a prominent part of this conference. I listened to several research presentations and volunteered to be a commenteer for one research paper.

The XP 2014 paper acceptance rate was somewhat selective, with over 50% of the submissions rejected. Research topics were wide-ranging including a case study on UX Design, a survey of user story size and estimation accuracy, another on agile development practices, a case study on visualizing testing, another on agile and lean values, and one comparing scripted with exploratory testing. Short papers touched on agile organizational transformations, Randoori Coding Dojos, and how expertise is located on agile projects. In addition, four experience reports were published (in contrast, 27 experience reports will be published and presented this year at the Agile Conference).

If the research papers I sampled are an indicator, PhD students seem to be busy doing empirical studies on agile practices, processes, and values. If you go to the Open University’s website you’ll see these topics listed under their Empirical Studies PhD program: The emergence of Agile software development, the role of physicality and co-location in agile software development, and XP and end user development

Agile software development is being studied and data being collected. The paper I commenteered, “Why We Need a Granularity Concept for User Stories” by Olga Liskin and her colleagues, reported on results gleaned from surveying developers (who self-selected themselves as agile developers) working on both private and open source projects on GitHub. I had three short minutes after the presentation to carry on a dialog with Olga about their findings. Fortunately we also had more time to discuss her work over lunch.

This paper raised as many questions in my mind as it answered. On small projects (10 people or less), 55% of the respondents said they did not estimate their stories on a daily basis. Is this an affirmation of the No Estimates movement, or just how people work on certain kinds of projects? Open source projects are quite different from product development. (Not all of the GitHub projects were open source ones, but still…). Depending on your project, you may simply work off a backlog, not necessarily do any estimates to forecast how much you can accomplish. Several developers I know only \break down their work into identifiable tasks. Effort estimates (as long as they know how to do the work) aren’t that important. They’re done when they are done. And if you build shippable, workable software each sprint, well, you always have something potentially useful to deliver.

Here’s just a sampling of what I’d like to know: For those who estimated, how did story size correlate to estimation accuracy? And what happens when stories are split? Are estimates for split stories more accurate? And just how important is estimation accuracy to those who make estimates? It just something they did to get a rough idea, was it “required” of them, or did they effectively use estimates to plan and make forecasts? Did people who estimate improve their accuracy over time? It seems that if you are learning how to use a new technology, once you’ve spun up, estimates should be more accurate. But how long does it take to get up to speed on your estimates?

Not surprisingly, the authors found that the smaller the story size and the better known the technology was, the more accurate estimates were. Research results often confirm the obvious (but it is still it is nice to have some empirical evidence to back up our intuitions).

It their conclusions the authors don’t recommend a “best story size”. I’m happy they didn’t. They didn’t have enough evidence. Conventional wisdom says stories should fit into sprints (comfortably). Makes me want to know more about the accuracy of larger stories. It seems reasonable, that the more work involved, the more possibility you’ll miss something that may influence the accuracy of your estimate. And you also may fudge on your estimates just so you make sure a story fits inside a sprint (because you don’t want to split it). But estimates are just estimates. They shouldn’t be expected to be 100% accurate. How do people behave differently when estimation accuracy is rewarded (or worse yet, punished)? Estimates are just estimates. You learn to recalibrate your efforts when a task is harder or easier than expected.

The authors cautioned that developers’ views about story size and estimates need to be balanced by others’ concerns. Too many stories can be burden a product owner. Developers in dysfunctional organizations might pad estimates, just so they have some slack (does anyone knowingly pad estimates? I’d like to hear from you.).

So is it better to bundle up small, related stories and estimate them as a single unit? Maybe. Back in the days when I had to estimate work, I didn’t like tasks being too small. If they were, my manager would look at them more closely (I’m not sure why). I remember once telling a manager, you can ask what we will be doing every day and how long each task will take, or we will guarantee that we will deliver all the features above the cut line in the next two weeks. But you can’t have both daily accuracy and predictability. She backed off on knowing exactly what we were doing every day (as long as we weren’t stressed out). This was long before the Agile software development movement, but it still seems relevant. Our small team worked off a prioritized list of features. It didn’t matter who did what task, whenever a task was finished, the next one was picked up. And we finished our work on schedule…because we wanted to make our commitment.

Here’s one parting thought about empirical studies. I’m very wary of biases that work their way into them. Those who answered the agile estimation survey might be very different from those who did not. Self-reporting of any thing we do (whether it be software estimation, the amount of food we eat, or how much we exercise) is notoriously inaccurate. We underestimate our weight, overestimate our capabilities, and don’t remember accurately. More accurate evidence is obtained through field studies where people are observed working. I wish more software empirical researchers could have opportunities to work directly agile teams and spend significant time getting to know them and how they work (in addition to just asking them questions).

Making Strong, Lively Centers





















Being aware of variable scope and limiting it.





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.

Discovering Lively Centers

Two weeks ago, Joe Yoder and I conducted a workshop on Discovering Alexander’s Properties in Your Life at AsianPLoP, the patterns conference held in Tokyo.

I’m still reeling from the many feelings that were stirred up as I prepared for this workshop. Inspired by the beauty we found in Kyoto, I included several photographs I took of that very beautiful place. Each property was illustrated with some image that resonated strongly resonated with us (whether taken in Kyoto or not, each photo had a strong personal connection).

Before I tell more about the workshop, I want to give a gentle introduction to Christopher Alexander’s ideas on properties of things that have life. Fundamental to Alexander’s ideas is the notion of “centers” arranged in space. According to Alexander, things that have life exhibit one or more of fifteen essential properties, which include, among other things, strong centers and boundaries.

Alexander’s notion of a “center” is simple to grasp—it is a coherent entity that exists in space. Individual centers are important (and they exist at different levels of scale), but more profound is how centers are arranged in space to form a more integral whole. Alexander writes,

“The system of these centers pays a vital role in determining what happens in the world. The system as a whole—that is to say, its pattern— is the thing which we generally think of when we speak about something as a whole. Although the system of centers is fluid, and changes from time to time as the configuration and arrangement and conditions all change. Still, at any given moment, these centers form a definite pattern. This pattern of all the centers appearing in a given part of space—constitutes the wholeness of that part of space. It is this structure, which is responsible for its degree of life.”

Here’s a photo I took in Hawaii for a talk I gave several years ago on the Nature of Order at another patterns conference. It illustrates the notion of a strong center:

I like this photo because it shows that the center of individual orchid flowers are accentuated and strengthened by the brown spots and five petals that form a star shape that surround. Not only is there a “center” to each flower (the stamen surrounding the pistil); there are several “centers” that surround that innermost center.

And here is the photo we showed at our Asian PLoP workshop to illustrate strong centers found on the roof line of an Imperial Palace building in Kyoto:

I leave it to you to find all the centers in this photo. The center cap on the top of the roofline accentuates the gold flower underneath. Underneath that is another circular center. Below that a symmetrical scroll. And there are centers (gold flowers) arranged along the roofline. Centers, when arranged in a pleasing fashion, complement and strengthen each other.

Centers are strengthened by boundaries that surround, enclose, separate, and connect them. Here’s a photo I took in Yellowstone Park of a crusty boundary at the edge of a bubbling hot springs:

The boundary between the hot spring and the land surrounding is fluid and ever changing (witnessed by the salty stains left from evaporation at the water’s edge).

The wood slats wrapped around this tree at the Imperial Palace in Kyoto, protect it from the wooden brace and form a boundary between the tree and the support:

After, explaining and illustrating Alexander’s fifteen properties, we asked attendees to form groups to brainstorm and discuss Alexandrian properties that they found in their own lives. One group focused on Alexandrian properties they found in the Tokyo metro and railway system; another on the properties of bento boxes; and a third on properties in education and learning. I was surprised by the diversity (and how profound some of the examples were, even though at first blush they seemed straightforward and simple).
But that is the topic of my next blog post.

To close this post I want to share two photos that whimsically illustrate “life” my camera eye unexpectedly caught in Kyoto. This first photo is obvious:

The second takes a little bit of searching to find the “owl-like” creature:

Is Kyoto a magical place? I think so. It was amazing to discover human-like or animal-like images in photos of trees. I had no idea that those shapes were there until I looked at my photographs. My eye must have been unconsciously drawn to those shapes (but truly, I didn’t see them until I looked at the photos). Even more startling to me is the liveliness of inanimate things—whether a hand crafted software module or a carefully placed garden pathway—that is more subtle and also profound. When we find strong centers surrounded by other strong centers in designed things, there is a pleasing sense of discovery and wonder.

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.