The Christopher Alexander Effect

Why does some design advice work for some people, but not for others? And why do some agile practices work for some people, but not for others? I call that The Christopher Alexander Effect and explain how it works.

Transcript

[00:00:00] Eric Normand: What is the Christopher Alexander effect? Hello, my name is Eric Normand. And this is my podcast. Welcome.

[00:00:14] So Christopher Alexander is an architect and mathematician. Who is best known for his book, A Pattern Language. Which talks about patterns of building that make the building better for the people inside. And he also wrote a book called A Timeless Way of Building.

[00:00:41] Now, interestingly he is often credited, correctly, with being the inspiration of both the design patterns movement in software engineering and also agile.

[00:00:56] So this person from a totally different field has had a very profound effect on software engineering. Just by inspiration, he didn't do it himself. He didn't set out to do it.

[00:01:10] But I want to talk about a thing I'm calling the Christopher Alexander Effect. It probably has a name already-- this phenomenon. But I need to tell the story as a narrative so that you can understand this effect.

[00:01:23] So Christopher Alexander is known for creating very livable buildings and groups of buildings. A college campus, for instance. And he wrote this book, A Pattern Language, which says: There are some patterns that we can recognize from human buildings. Because humans have been building buildings for thousands of years. They know a thing or two. And we can observe those things, and write them down, and call them patterns. The book is a catalog of patterns at different levels. So patterns for cities, patterns for neighborhoods, patterns for buildings, patterns for rooms.

[00:02:15] And people say that it really helps them design their office or, they built a house using those patterns and it really was helpful.

[00:02:23] But he generally considers it a failure. Christopher Alexander tells stories in some of the books, where people say: Hey, look, why don't you come see my house? I followed the patterns. Christopher Alexander goes and sees it and is like, ah, that's not really capturing the thing that I intended you to capture. I mean, I get that you follow the pattern. I see it. I see that this pattern was followed. But somehow you missed something.

[00:02:55] And that would happen over and over again.

[00:02:57] This idea of capturing the patterns and writing them down so that people could learn from them.

[00:03:05] It didn't work. Some people could learn from them. Some people couldn't. Some people already seemed to know that those were good patterns. And that now they had a name for it. And someone took the time to write down all the aspects of it. Maybe there were some aspects that they hadn't thought of. So it was kind of useful to them.

[00:03:25] But as a way of teaching architecture to someone who didn't know architecture, and wasn't already very good at it. It kind of failed.

[00:03:32] And this is what I'm calling the Christopher Alexander effect.

[00:03:36] A very experienced person or a person who's just good at it for some other reason, these patterns help them.

[00:03:44] But, someone who was not a good architect. The pattern might actually just be a distraction, might get in the way.

[00:03:52] It's getting in the way of the deeper understanding, the intuition that you need to apply the pattern in the first place.

[00:04:00] And this is the problem I see with design patterns, the computer software idea.

[00:04:06] There's a lot of people who love design patterns. They're good designers and they say, wow, every time I read about design patterns, I learn something. It's very valuable to me. I don't understand why people don't like them.

[00:04:19] But then you also see beginners, or people who just aren't that great with design taking the same ideas and using them in the wrong way. Overusing them. Just simply not understanding how they make the software better.

[00:04:33] It simply names things for people who are already good. And the people who are not good, it doesn't help them and maybe it hurts them.

[00:04:40] I don't want to put blame on people for making people worse programmers. I don't think that's actually happening. I think if you're a bad software designer, that's something you need to get better at. It's not the fault of someone for writing down things that are helpful to them.

[00:04:55] But this is the effect. It helps people who are already good. But it doesn't help make people who aren't good, good.

[00:05:03] That's what I'm calling the christopher Alexander effect. I think that there's a similar phenomenon happening in agile.

[00:05:10] So just a brief history of agile. It's an over simplification, but it'll do.

[00:05:16] Once upon a time, everybody did what the agile people call waterfall, which is a very rigid process. With steps. The steps would often take maybe years to complete.

[00:05:31] So it's a very long process and each step might even be performed by a different person or a different group of people. So you would have requirements gathering. Subject matter experts writing down all the things that they think the software needs to do.

[00:05:51] And then they would take that document. And pass it to the architects. And the architects would design the software based on those requirements. Okay, so they just read it and they'd say, oh, the software needs to do this. We need to have a database that looks like this. And they write out another document. Then they'd take that document and hand it to the next group of programmers, engineers. And they would sit there and read it and do their best to make software that did what the architect said it should do. And this could take years. You could have a six month requirements gathering phase. And then a six month architecture phase. And then a four year programming phase. So agile comes along and says, that takes too long.

[00:06:45] The requirements weren't gathered, right. The architecture was based on faulty requirements. And then the program was based on the faulty architecture.

[00:06:54] So we need to cut this shorter. More iterative development. We want to be able to get software out faster. So it's not a complete software, but it's something, get it out faster. Give it a try. And then work on the most important thing next. Those aspects of agile do work better structurally.

[00:07:19] But it leaves out the details. How do we actually work? What does talking to customers look like? Before we had people who might be trained in how to gather requirements. And now a lot of that work is just passed on to programmers. But do they know what to ask? Do they know how to design a system like an architect does?

[00:07:44] There's these questions that are left unanswered. When you, when you move into the agile world, But agile does seem to have some success. My hypothesis is that a lot of this is the Christopher Alexander effect.

[00:08:01] You have this bureaucratic dysfunctional process like waterfall that is actually getting in the way of very talented people. During the agile revolution, there were some older people more experienced software engineers who had grown up in this regime of long waterfall processes. And they got good. At dealing with this process, it got in the way a lot. But they got good at.

[00:08:37] Reading a thing from an architect.

[00:08:43] And seeing, oh, you know, I wish I could ask the customer. This question and that question. Because last time I trusted what the architect wrote. And just wrote it. It turned out that the customer didn't really want it. And now I can see that if I could just clarify this one thing from the customer.

[00:09:05] I would be able to write the right thing the first time.

[00:09:08] Or if the customer only knew that that was going to take six more months to do it that way. But I have a way of doing it in a week. If they knew that maybe they would let me do the week version of it too. It would just leaves out this little feature. Maybe they don't even want it that bad. Right. So there's these questions that you learn to ask only because you grew up in this more repressive regime.

[00:09:38] And so when the agile revolution happened, and the process was stripped away. The early agile community, the folks who signed the manifesto, were given the reigns. And they said, well, I know how to do all this. I'm just going to get rid of all the process.

[00:09:59] And we're going to do it very. Very minimal process.

[00:10:04] They were freed. All of their skill and talent and experience was now able to be used.

[00:10:11] Right. So they were very, they were good. At software engineering, all aspects of it.

[00:10:20] But then what about people who say, start now? Are they going to be able to just do well in this agile environment?

[00:10:33] Where there's very little process and very little guidance about what to do next.

[00:10:40] I see this a lot. Teams are doing all the agile right things. But there's something missing. They're not thriving. They're not making great software. They're not getting great feedback about what they're building, whether it's the right thing, and making their customers happy. It just doesn't seem like it's automatic.

[00:11:07] And so I hypothesize that this is another instance of the Christopher Alexander effect. You see some parallels between what Christopher Alexander said. Some people who are already good seem to use the patterns well, but other people felt like they were following the pattern. That it would automatically lead to a great house. And it doesn't.

[00:11:34] And you see that same thing where some of the signers of the agile manifesto are saying this isn't what we meant.

[00:11:45] And then people are like, but I'm doing all the practices. I've got a two weeks sprint. And we're doing continuous delivery and they just list all the practices.

[00:11:55] Yeah, it's, it's one of those things where we're still learning as a, as a discipline. As an engineering discipline, it's been a while, but we still don't know how to do it.

[00:12:09] We still don't know how to do project management. We're still bad at it. And I think we're going to suffer from this Christopher Alexander effect for a long time.

[00:12:21] Another flip side of the Christopher Alexander effect is that dark underbelly where people get fascinated by the patterns.

[00:12:31] They think that they hold some secret, the design patterns. If I just use another visitor pattern with a decorator and a factory, maybe it'll be good design.

[00:12:42] Or if I just have a better scrum. If we just use user stories a little bit better, more strictly, we'll capture some magic.

[00:12:52] That's the dark underbelly of the Christopher Alexander effect.

[00:12:57] So again, The patterns are real. Design patterns are real.

[00:13:04] But they're merely names for things that good designers will do.

[00:13:11] But it's not making non -good designers good.

[00:13:15] And scrum or agile are not making non good project managers good.

[00:13:22] My name is Eric Normand. This has been another episode of my podcast. Thank you for listening. And as always, rock on!