Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Podcasts Linda Rising on the Importance of Patterns, Her Journey & Patterns for Driving Change/Innovation

Linda Rising on the Importance of Patterns, Her Journey & Patterns for Driving Change/Innovation

On the InfoQ Podcast this week, Wes Reisz talks with the Queen of Patterns, Linda Rising. Linda discusses her thoughts on the importance of patterns, she answers questions about what really is a pattern, and how she became involved in working with them. Throughout the podcast she discusses a variety of organizational and personal patterns and finally wraps with patterns to apply when driving change and innovation

Key Takeaways

  • You have to realise that there’s nothing you can do about other people. The only person you can affect is yourself.
  • A pattern is not a band-aid that you use once. You use it in a context where you use it in conjunctions with other patterns.
  • Take baby steps when driving change in an organisation, and seek out a pocket of receptive people to drive it.
  • Slack is an important part to have in life, so that if something comes along you can absorb it without having to stop doing something else.
  • Listen, Listen, Listen.

Show Notes

Linda Rising is well known for her work on design patterns, retrospectives, and influencing strategy and agile processes. Today’s podcast discusses her involvement with patterns and how they have evolved through to today.

What’s on your mind today?

  • 2:00 - Division within the country. As developers, we’re familiar with divisions - such as the division between testers and developers, where they would throw the code over the wall to testers.
  • 2:50 - Whenever testers found a problem they would blame the developer - you think they would embrace that, but instead they would blame the testers for finding problems in the code.
  • 3:15 - It’s the extent that things have gone so far in the country today, that we can’t talk to one another - and if we can’t do that, how are we going to interact with one another in a different context?
  • 4:30 - Because of this political division, I became interested in the science of how we understand one another.
  • 4:50 - I’ve been talking about how we might take advantage of new research to allow us to communicate better.

What can we learn as developers to communicate better?

  • 5:40 - There are several patterns from “Fearless Change” that Mary Lynn Manns and I wrote about organisational change.
  • 5:50 - The one that comes to mind is “Fear Less Change”; when you run into people who disagree with us we typically avoid or denigrate them.
  • 6:20 - The pattern says that you don’t need to be afraid of that interaction; you need to build on it - and the way you do that is by listening.
  • 6:40 - The research that supports the pattern is from experiments - what they found was that once a gut feeling is established, then facts and evidence don’t change that.
  • 7:10 - Confirmation bias is the worst kind of bias - people will only hear and agree with what they want to agree and hear.
  • 7:30 - That applies to people listening to this podcast; if there’s anything in here they don’t like, they’ll just skip right over it or denigrate the speaker.

How do you break confirmation bias?

  • 8:15 - You have to realise that there’s nothing you can do about other people. The only person you can affect is yourself.
  • 8:25 - With any discussion - about a bug, a design feature, the architecture - the only way you can approach it is by learning and being open yourself.
  • 9:00 - In negotiations, there’s no difficulty in getting people to come to the table to discuss issues.
  • 9:10 - They assume if the other side is being intelligent or logical, then they can use facts to convince the other side of their point of view.
  • 9:20 - The problem is that both sides think the same thing.
  • 9:40 - If no progress is made, then you think that the other side isn’t as logical or as intelligent as you thought, or that they weren’t listening.

How did you get started with patterns?

  • 11:00 - I did the same thing as everyone else did - we went to OOPSLA (the Object-Oriented Programming, Systems, Languages and Applications conference).
  • 11:30 - One year there was a tutorial called “Design Patterns” by four guys - it was full, standing room only.
  • 13:00 - The book was available at the conference - there was a long line out - which I took home and read.
  • 14:00 - The powerful things that came out of the book weren’t the ideas - they were already known - but now we had a common vocabulary of what they were called, like Mediator.
  • 14:30 - This allowed us to become better communicators about conveying intent.

How would you define a design pattern?

  • 15:20 - It’s a little package with a tag on it that says ‘Mediator’.
  • 15:30 - When you know what the tag says, you don’t need to open it - you can pass it around to your friends.
  • 15:45 - Every now and again, when you find someone who doesn’t know what a Mediator is, they can open the package and see what it means.
  • 16:20 - A pattern is not a band-aid that you use once. You use it in a context where you use it in conjunctions with other patterns.

How do you organise patterns?

  • 18:00 - It depends - what came out of the Gang of Four book was more than just a publication; it was a community.
  • 18:15 - The patterns conference grew from the University of Illinois out to four or five other conferences.
  • 18:30 - As well as describing other patterns, we also asked philosophical questions, like how can you categorise them, and what is a pattern?
  • 19:15 - One of the guys who worked on patterns was John Vlissides, who worked at IBM.
  • 19:30 - He said we were going to do something like the farmer’s almanac, and come up with a new version every year.
  • 19:45 - I wrote the patterns almanac 2000, with a lot of help from John and others.
  • 20:00 - One of the problems was how to organise it - do we do it by domain? So there was a communications patterns, architectural patterns, fault-tolerant high-reliability organisational patterns.
  • 20:15 - We never got a perfect organisation of the patterns. Not even when we had Christopher Alexander, who gave a keynote at OOPSLA one year, had organised his architectural patterns from large to small.
  • 20:50 - I’m going to PurpleSoft in Vienna in October, and that’s one of the things we’re going to talk about.
  • 21:10 - People are still writing patterns, but they are write only. At the time I wrote the almanac, I only included patterns that had been previously published.
  • 21:35 - Now there are orders of magnitude, more patterns, but finding them is more difficult.

So what makes a pattern?

  • 21:50 - If you look at a pattern, it’s supposed to be a solution to a problem in a context.
  • 22:30 - You also have to come up with a list of known uses - who has used this solution and applied it successfully?
  • 22:50 - My proposal for October is that there must be evidence to support the existence of a pattern.
  • 23:00 - Even in the agile community, where we use the phrase experiment all over the place, we are just doing stuff.
  • 23:15 - The scientific method has a process for performing experiments; there should be a hypothesis which the experiment is designed to answer.

What was introducing scrum like in the ‘90s?

  • 24:50 - AG Communication Systems (which no longer exists) was an open, agile organisation.
  • 25:10 - I felt encouraged, listened to, open to ideas - and it was that, rather than anything I did.
  • 25:35 - When I arrived in the organisation, that’s the way it already was. No one there knew what the path was to get to that point.
  • 26:10 - I learned that even within an open organisation there are patterns.

What are patterns you might suggest when driving change in an organisation?

  • 26:20 - The first one would be small steps, now known as baby steps.
  • 26:35 - CEOs often start with an aspirational goal - that we will become agile - and they want a timeline, milestones - and like other estimates, it’s a lie.
  • 27:00 - The best thing you can do is very small steps, and go to the parts of the organisation that are receptive - there’s always a pocket of them somewhere - and go where the people will listen and are open to experiment.

Can you explain why having slack in your life is beneficial?

  • 27:40 - I used to work for a very, very small company - you can correlate the size of an organisation with the average intelligence, though that might be self-selection.
  • 28:10 - In a small organisation, everything is very visible and so there’s nowhere to hide, whereas in a large organisation there are plenty of places to hide - there’s more slack.
  • 28:30 - I was going to start small, run brown bags over lunch, talking about patterns.
  • 28:45 - It went nowhere. Not that they didn’t get it, or they weren’t smart, but they had no time for anything - no slack.
  • 29:00 - Tom Demarco’s book “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency” which talks about the importance of having some slack.
  • 29:15 - For the large organisation, they had slack, so they could spend time getting to learn how to use patterns and apply them.
  • 30:00 - I’ve just finished reading “Deep work” - it’s the lack of focus and space for innovation, because we’re buried in the trivial.
  • 30:20 - Social media and e-mail is eating us alive - you have to schedule slack into your life: put that phone away!
  • 30:55 - I heard a podcast by Geoff Colvin (who wrote “Talent is Overrated”) and he said that you can schedule innovation - inspiration is overrated.
  • 31:10 - If you don’t have any space - or slack - in your life, where you can’t follow up on the idea that you had - then you can’t be innovative.

What is your most recent discovered pattern?

  • 31:40 - It’s a rediscovery of an existing pattern.
  • 31:50 - I was researching morality and ethics - if you can do an experiment on morality and ethics, you can do an experiment on anything - and I was trying to apply the techniques as facts.
  • 32:40 - The most important key in communicating is an old pattern - listen, listen, listen.
  • 33:30 - I don’t know if you’ve read the “Seven Habits of Highly Effective People” - the author is sadly no longer with us - but he said “Seek to understand, not to be understood”.
  • 33:55 - I can remember having a conversation with someone who didn’t like patterns, and all I did was listen, but in the end he said he would give it a go.
  • 34:15 - I listened him to agreeing with me.



Book: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
Book: Deep Work
Geoff Colvin on Why Talent is Overrated - Podcast, Book
Book: The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
Book: Fearless Change


More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article