Communication Patterns: A Guide for Developers and Architects

Intro

Gregor Hohpe: Welcome to the "GOTO Book Club." My name is Gregor Hohpe. Last year, I had the chance to discuss my book with James Lewis, so I want to return the favor and have a chat with Jacqui Read to talk about her book, "Communication Patterns." I actually had the pleasure of meeting Jacqui in person when we were in Athens, out of all places, so I have a lot of good memories about talking to Jacqui about her book and want to have, you know, about 40 minutes today to chat with her about how the book came about. So Jacqui, how are you?

Jacqui Read: I'm very good. Thank you, Gregor. And yes, it was really nice to meet in Athens. Very nice country to have some talks and meals and things, wasn't it?

Gregor Hohpe: Every time I look at a book, I remember the sunshine and the nice dinner we had. Of course, as a fellow author, one of my experiences, of course, is that writing books is fun, but sometimes also less fun, right? It takes a lot of work. So I always like to ask folk, like, what actually motivated you to want to write a book, and also what helped you actually complete the book? Because often those are quite two different things.

Jacqui Read: Yes, definitely. So the kind of thing that motivated me was that when I started working as an architect, before that I did .NET development, but when I moved into architecture, I realized that actually communication skills are really, really important, especially in the architecture realm, but they're really actually important to developers as well. And it struck me that actually quite a lot of people don't have particularly well-developed communication skills or haven't had the chance to really develop them.

And I particularly noticed a big problem with diagrams. They're just not very good really, hard for anybody to understand. And so there weren't really any books on that. There are loads of books on the technical aspects of architecture, but what about the underlying communication to it? So what's the point of perfecting your technical aspects if you can't actually then communicate them to either the people making the decisions or the people who are gonna implement the architecture?

So most people call them soft skills, but I really call them core skills because everybody needs these to be successful in their role as a developer or an architect, a product owner, or a CTO. Everyone needs them. And almost everyone prioritizes learning about the technology, going to the Kubernetes talk at a conference or the course on event-driven architecture over anything relevant to these core skills, which everyone really, really needs. And so I really wanted to give people that information that they needed and give it to them in one place. And so that's where the book came from.

Recommended talk: Platform Strategy • Gregor Hohpe & James Lewis • GOTO 2024

Communication Patterns in Tech Communication

Gregor Hohpe: I like that notion a lot. Often, soft skills sound a little bit, like, nice to have, kind of, hey, while you edit, maybe you acquire some soft skills. I would easily agree with you that drawing a good picture or getting a point across clearly, that's not a nice to have add-on. It's not about waving your hands while you're on stage, right? It's actually getting across what you're doing and illustrating the decisions you're making about the architecture. So I like that notion a lot, right? This is a core skill, not something that you may do when you have time.

Now, obviously, a lot of folks feel that communication is important, right? If stuff is in your head as an architect but you can't get it across to other people, then that's good for you but that's not good for the project or for the other folks. So I once contributed a little bit to a book that Neal Ford and his colleagues had written. I think it was called "Presentation Patterns." So very much on visuals. "The Architect Elevator" has a whole section on communication. I think you actually quoted the "Pirate Ship" chapter out of this.

So how did you frame your work within the context of other works or other things that people have written about technical communication skills?

Jacqui Read: Well, as I said, my main aim was to make a comprehensive resource for everybody really in the software and the technology industry. And when I was looking at this, I needed to research the current market when I put my book proposal together for O'Reilly. And so I saw that there were some aspects of communication covered here and there. So as you say, "Presentation Patterns," that's an excellent resource for anyone who's giving a talk or a presentation, but that's very much just about giving talks and presentations. There's a few things that you can apply elsewhere, but it's all aimed at the talks and presentations, which not everybody does, of course.

Then the communication section of "The Software Architect Elevator," that's got some excellent content. And that's why I reference it. I particularly love the name of the "Show Them the Pirate Ship" chapter. I always end up quoting you when I'm giving talks on that. So I highly recommend that to people, especially architects, and things. And that was actually one of the larger bodies of communication knowledge that's slightly more generic rather than just focused on one thing. But I saw there were gaps and I wanted to collect together information that was scattered around a bit but also put in all the things that I'd gained from my experience.

And so one of the big things I did with "Communication Patterns" was to use my knowledge of other realms to apply things from there into that realm of software, things like graphic design, even personal productivity concepts, they've been brought into the book as well. Because there's this huge Venn diagram of all these different areas. And so if you become a very, what they call the T-shaped sort of technologist and go very deep into one area, you're missing out on other things. So you want to be kind of M-shaped maybe, or maybe even going a bit further, lots of viaduct arches shaped.

Gregor Hohpe: Sometimes called the coom, right? You've got to have many legs on the backbone.

Jacqui Read: I could see really with visuals that was one of the really big problems. There are so many diagrams that could be so much better with just a few changes in them. And so the first part of the book contains 21 practical patterns and anti-patterns. And I really wanted to give actual practical advice that people could apply straight away. That was really important to me. There's no point in just giving people the theory so that they can't apply it, but there is an explanation in there as to why you need to do this.

There are also some large holes in the areas of communicating knowledge and also communicating with remote colleagues or customers. I covered those. They've each got their own part, their parts three and four. Then part two, that covers technical writing, but it also covers things like how we encode and decode messages as human beings.

I thought that was quite a good analogy to use with technical people, because, of course, when we're writing code, we are always encoding and decoding messages, sending them in various different ways. So I've always tried to aim it more at a technical audience, whereas any of the information that is anywhere else is very scattered and not aimed particularly at technical audiences. So it's really nice and focused for people.

Gregor Hohpe: It's true. It's not just about making a pretty picture or making nice sentences. You really have stuff to get across as a technical person. I mean, it is complex, right, to begin with. So you got to deal with that. I was very happy to see that the first part of the book is all about visuals, and in "The Architect Elevator," I think I have, like, five or six pages worth of space on how to make a good diagram. And I was able to make the point, like, you always gotta put some lines, but at the end, then you have a lot more space. And what I like particularly is that you have a lot of examples like good and bad, before and after, right? Because in the end, I think that's the way people can learn.

Now, you said a little bit of a dangerous word for book authors, and especially in the area of communication, and that's the word comprehensive, right? So people draw, people write, people speak, they collaborate remotely, right? You probably could have written, like, five books on all this. So how did you manage to package this? How did you do the scope control? Or how did you find what was on the sort of inside of the Venn diagram where things overlap in a meaningful way?

Jacqui Read: That's a really good question. Yeah, scope for a nonfiction author, just like when you're trying to put a software project together, is very hard to control. So, it's the balance really of including what's relevant and useful but not overwhelming the reader with too much. There's no point in giving them sort of an encyclopedia because they're not going to read it all.I did try and condense things down when I was writing this.

I would say it's generally safer to go for less rather than more, which is very hard to do. So anything I didn't put in, I, of course, didn't throw away. That might be used for something else. But when I was initially asked to do the book, it was supposed to be about 200 pages with the 4 parts. And then I wrote the draft of the first part, so what was supposed to be the first quarter, and that turned out to be about 100 pages by itself. That included images, though. And that is the part of the book that has the most images. So it is actually more...in the end, it was more than a quarter of the book. So I did manage to cut that down from its original draft.

But then I did get agreement to aim for 300 pages. I was told for no more than 350. I think it ended up something like 306. So actually, that's not bad, because that includes all the publisher pages and stuff as well. So I think I did quite well with that in the end. But yes, very difficult to decide what goes in and what doesn't.

Gregor Hohpe: I just checked, like, I got it right here. I checked, like, 282 in the printed version. So it sounds like you went through the exact same cycle of, "Oh, I don't have enough to write about," and then quickly it turned into, "I have way too much to write and I don't know how to actually fit it in a book." And that's something that is not uncommon amongst book authors, right? Once you get on it, once you get feedback, more examples, you think about it, you use it in your daily work, the stuff just mushrooms.

Recommended talk: Collaborative Software Design

A Framework for Effective Tech Communication

Gregor Hohpe: You said the structure of the book really has four main parts, right? You talk about visuals, like how to make a good diagram, you talk about writing, you have knowledge management, and you have remote collaboration and communication, given that the time the book came out so that by the end of the pandemic we have a super relevant topic.

Now, was that a structure that you had in mind right from the beginning? You said, "Hey, those are the four legs, the person the reader needs to stand on?" Or did this emerge as you went along?

Jacqui Read: Well, the visuals being first was always the plan, because that was the first idea I actually had for the book because it was the biggest thing that I'd seen and also what I considered probably the easiest problem for people to fix themselves once these things are pointed out.

One thing I really hope with the book is that once people have seen these things, they can't unsee them. And therefore, every time they create a diagram, they just have to follow them, because otherwise they won't like their own diagrams.

So I split the visual patterns and anti-patterns in the first part into six categories, such as things like notation, and there's one on clarifying the clutter, so getting things out of diagrams. And so those then became six chapters. They're only the main categories though. So as I was talking about earlier, like the Venn diagrams and connections. So all these kinds of patterns and anti-patterns do relate to each other and tend to be used together. So that was always going to be the first part of the book.

And then I came up with various other things... I kind of always knew I thought there would be a sort of knowledge area. At first, I started calling it documentation, and then I thought, "Well, actually, no, it's not just about documentation," and people don't like the word documentation anyway. So it's more than documentation. It is about communicating knowledge.

Gregor Hohpe: I agree..

Jacqui Read: And then the remote section became something that was fairly obvious as well because, as you say, a lot more people work remotely now. And then we also...it's not just about people working from home, it's people working in organizations where there's people in different countries, or even if you haven't got colleagues in other countries, you've probably got customers in other countries as well. And so there's lots in there about thinking about time zones and lots of different ways of making it easier to communicate with people who aren't in the same office as you because it's very, very different.

I think a lot of people were sort of slapped in the face by the fact that it is so different when COVID hit, and everyone was forced to do this. Everyone realized that they weren't very good at communicating, even via video calls. Yes, so those three parts were very kind of definite.

Then part two is kind of more a collection of written, verbal, and nonverbal patterns. And so these were all patterns that I was seeing. And it's kind of the written technical stuff that tends to be a bit more available for people to find on the internet. But again, it's all kind of scattered and all aimed at different people and things. So I thought, "Right, I'm going to gather this all together." And it ended up being called multimodal communication, for lack of a better word.

We all know that naming things is very hard. I think it's probably a fairly reasonable one there. But things like there's a pattern in there called acronym hell. And that one actually started out as one of my visual patterns, but then it was relevant mainly to writing. And so that ended up being moved to part two. So things did get moved around and kind of all sort of came together into this kind of living, breathing thing.

Gregor Hohpe: Books will get refactored just like code gets refactored. I refactored virtually all of my books. And yeah, regarding remote communication, this is a great example. So we are 7 time zones apart now and probably 20 degrees centigrade climate difference. We have come a long way...

Jacqui Read: At least.

Gregor Hohpe: We are a good example of this.

Recommended talk: Software Architecture for Developers Part 2/2 • Simon Brown & Stefan Tilkov • GOTO 2021

Effective Visuals and Flexible Use of Communication Patterns

Gregor Hohpe: And coming back to the visuals, right, again, I love that you anchored this because it seems so easy. Like, oh, you make a sketch, you have an architecture diagram, there's UML, right? So you would feel like, hey, we're all in good hands here. But in the end, making a really good sketch is much harder than it seems.

So one question I wanted to ask you, so we're both good friends of Simon Brown and the C4 method. So do you have thoughts on when are architects better off using a standard notation? You know, let's say C4 or UML or any of the other popular ones, versus when should people sort of ad-lib, you know, go and develop their own style or make their own notation? Is there kind of any hint on that?

Jacqui Read: I think my thoughts on that are that you really need to think about the audience, what they're going to understand, and also what you want to communicate. If you're communicating behavior, then you want to go for a behavior-style notation. Thinking about even things like flow charts, sequence diagrams, data flow diagrams, things like that. And if you're communicating structure, then you can go for things like C4 and all the various other structural diagrams that you can use.

So the behavior and structure is a big thing. But you don't have to use one of those formal notations if people understand it. And especially if you've got a legend or a key, that's one of the things that I tell people to include. Even if you think you understand it, there'll be somebody else who will misunderstand something if you're not really specific about it.

So I don't think anyone should ever be forced to use a particular notation. I know some companies still do say, "We only use UML," which isn't particularly good in this day and age because UML has a lot of detail in it and it's very hard to decipher it without a full key. And, of course, people don't put the key in. So it takes a long time to create a UML diagram because of all the detail. And then it goes out of date very quickly because of all the detail in it. It's much more likely to go out of date. So I don't think anyone should ever be forced to use a particular notation. It should be, what am I trying to communicate? Is it behavioral or structural? And how are people actually going to understand this?

One of the main patterns in the first chapter of the visuals part, which I call the fundamentals, because if you can get those right, then you can build on top of them, is about thinking about your audience. Because with a diagram, sometimes your diagram is going to be all for technical people. Sometimes it's going to be all for more business people, but a lot of the time it's going to be for both. And that makes it a lot harder to work out what you should put in that diagram. So I recommend people have a look at the audience to help them with that.

Gregor Hohpe: Very true. It seems so obvious, but so easily forgotten, right? And my common saying is, always make sure the tool works for you, not the other way around, right? The danger with some of the big standard notations is that you end up working for the tool. And I don't think that's the way it was meant to be.

The funny thing I happen to know, so one of the best-selling books on UML is for Martin Fowler, right, "UML Distilled”. And the funny backstory is that he didn't really want to write a book on notation. So he said, in the end, he only agreed because he could write a book on system design that was disguised as a book on UML notation. I think in the end, everybody won because people use it as a UML reference, so it's not all bad. But in the end, people also got a lot of subliminal messages on actual system design. That was sort of Martin's way of having his name associated with a UML book. It's been widely successful.

Coming back to the structure of the book. So I like the order and like the way you describe. You start with the visuals. We have the multimodals. We have knowledge management, right? It's not just documentation. It's conveying knowledge. And you got the remote. Then it sounds like I don't have to necessarily read the book from page 1 through, what do we say, 282, to page 282. I can pick and choose. So how do you recommend folks read the book?

Jacqui Read: I wanted to write it so that people don't just have to read the whole thing. So if you're really looking to improve your visuals, then you can dive in in part one. If you're thinking, "Okay, we're really struggling with this remote stuff, or we're really...our knowledge is all over the place," then you can just dive into those parts. And you don't necessarily need to start from the beginning of the part either. So I know some people have actually just sat down and read the whole thing. And if you want to do that, go for it. And then you can use it as a reference book afterwards as well. So it's very easy for people to use it as they want, really. I didn't want to prescribe how people should read the book. So pick and choose, do what you want.

Recommended talk: Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023

Patterns in Communication: Flexibility, Testing, and Exceptions

Gregor Hohpe: I've definitely done that where I mixed and matched and I consider this one of the great strengths of patterns books, right, that you can read cover to cover, but you don't really have to, which brings me, of course, I'm a big fan of patterns, brings me sort of to my next question, and that is, was that always your idea to document these insights, your guidance in form of patterns, or is that something that evolved later as you were writing?

Jacqui Read: I did always have that intent to write it as patterns and anti-patterns right from the beginning, mainly because that's a form of communication that people working in technology understand because it's used in software development, even software architecture. But also because I'd seen things like the presentation patterns book, "Gang of Four," things like that. And I quite liked that format. It made it easy for people to reference. It makes it quite practical, although it's still got kind of the backstory as well.

And when I originally wrote it, I did write it more in that format with headings, such as kind of definition, applicability. I think some of them are related patterns, things like that. But it didn't really match with O'Reilly's style. So we had to work together to create something that worked for both of us. And so my patterns don't specifically have those headings, but they do really contain that type of information in there in the text. So it's all very practical, but it does tell you kind of where it comes from, why you need to apply it. Because I think if you're going to give people practical things, people still need to understand why they're doing something. If you don't understand why, then you're probably not going to actually bother doing it and just do something very different instead. But I found that...

I found that actually, you can apply the patterns to kind of writing the book itself. And so there's a very meta example in one part of the book actually, where there's a bulleted list which tells you all these tips for creating a bulleted list. And then there's a little tip box after it. And it says, "If you're looking for examples of the tips in the bulleted list, then you should look at the list itself because it follows its own rules." So it's very meta that bit.

Gregor Hohpe: I noticed that you can use the patterns itself when writing the book. I had only the cheeky idea. I think the next example is using a table. And I thought, "Oh, it might have been kind of interesting to then write that as a table so that you can do the same thing." But yeah, it's cool to see when the author uses basically their own patterns. Like, in this case, it was about making a list where each list item has a similar grammatical structure, right? So make them all start with a verb, make them all have a similar kind of length. So when I looked at the list, I was like, "Yep, right, this is exactly what it looks like. So maybe we can try a table for the other pattern."

Jacqui Read: That'd be quite fun.

Gregor Hohpe: So what you said about the format is super interesting to me because, you know, patterns generally have a structure. If you look at "Gang of Four," Enterprise Integration Patterns," you know, the Christoph Alexander patterns, they have this kind of structure. But when Bobby and I wrote our book, we also went a little bit around in, do we actually have to label the sections of the patterns? Like, should the context say context, right, and should problems say problem? In the end, we also voted to not do that as explicitly. We used some soft formatting, some bolding, and the diagram. The sketch is always at a certain position.

I quite like that because if as a reader I want to follow the structure, I can, and I will probably recognize the structure, but I'm not forced into it, right? If I just read this as prose, probably that will work just as well. So it's super interesting to see also that they started with a more rigid structure, but in the end, you let it just be prose when the patterns ended up in the book. Very cool.

Now, one question we always have as pattern authors, right, so there's this...you know, and it's a little bit sort of the academic side. I don't mean this in a bad way. We all went to school for good reasons. But one of the things we like to say for patterns is, like, "Oh, you must have observed three uses and actual practice to sort of test, to sort of prove the patterns." So how did you go about testing them when you had an idea for a pattern? How did you validate that this is something that recurs all the time versus could have been just a fluke or a one-off?

Jacqui Read: I think with diagrams, that's actually a lot easier than finding these patterns in code and other things like that, because there are so many diagrams all over the place and you see them all the time in your workplace, but also there's loads of them sort of open source online.

If you can find good examples or things that look good to you and seem to work and compare them against the ones that don't seem to work, you can kind of see why one probably works over another. Like, you can see that, oh, this diagram doesn't work and it's got tons and tons of information in it. They've tried to just create one diagram rather than sort of several. And you can't understand it because there's loads of things in it. Whereas you look at other diagrams and you can see that, oh, this diagram has far less in it and I can understand it.

I think with diagrams, it's a lot easier to sort of spot these things. So yeah, just through my kind of experience, I've worked in various areas, so I've worked in security, education, geospatial as well, and I see this in all those areas the things that go wrong and the things that kind of work that they do repeat. And they repeat online as well when you see these different diagrams.

One of my pet hates at the moment, which seems to pop up on social media is these diagrams that have some kind of animation in them, like all the arrows animating themselves. And I look at that and I think, "I can't understand that because I can't get past the animation. It's awful."

Gregor Hohpe: These GIF things, yeah, yeah. I've made fun of them publicly before, yes.

Jacqui Read: Yes, they're just to kind of catch people's eye, and I would hate to think that anybody would look at it and go, "Oh, that's a good idea. I'll do that in my software documentation." Actually, it's really just to catch people's eyes so that the algorithm boosts them. Please don't ever do that. Anyone listening, don't do it.

Gregor Hohpe: And I publicly ridicule them. So a couple of thoughts on this. I mean, the one thing is often people have this misconception that books get written in the quiet chamber and probably the actual typing maybe does happen this way. But much more often, like, you work as a consultant, right? What I find is you have a concept or an idea for the book, a certain pattern or a certain section, or a certain way of doing things, and then you go test this with your clients, right?

You drop the idea in a conversation. You see how they react. You see good examples. You see bad examples. You see whether your idea actually improves the work. So it sounds like you've done the same kind of testing and validating. So in the end, the writing really is the result of feedback and mutual learning cycle much more than you just sitting down and writing page 1 and finishing with page 282.

Jacqui Read: Very much so, so with the architecture work that I've done in the past, the consulting work, my development work as well. So I've worked for companies and I've worked for myself with clients, and yes, I do sort of test these things out. I also teach workshops online and in person. You can get a lot of feedback from people in those workshops as well. So you get them from the actual in-the-trenches kind of thing, actual working, but then also from people in workshops. And people tend to ask really good questions, and you go, "Oh, great. I love that. I hadn't thought of that one. We can go deeper into that."

Gregor Hohpe: Yep. I do that. I always tell people I learned a lot in my own workshops, as funny as it sounds. It's definitely a two-way street. Now, your earlier comment on the blinky lines, right, the animations reminds me of another interesting aspect about making a good diagram, because for us as architects, aesthetics are relevant, right, even if you draw something that's correct and it's just, like, messy, and I think you have a pattern like the cobweb where the lines all cross, right? So that is technically accurate, like, the meta-model behind the graph is essentially accurate, but the depiction is just ugly and confusing. That matters. At the same time, they're not works of art. They're not just there to be pretty. They also need to convey the concepts behind it, right? The line between these two boxes means something.

I saw in your book that you also tackle both aspects. So some are, like, visual and layout-related, and other ones like level of abstractions are very much related to the content and the actual architecture. Is that sort of one way you thought about these patterns?

Jacqui Read: Yes. So some of them started out maybe as one pattern and then actually got split out because it's much easier if you think about all these different things as different concepts and then you can apply one after the other. So as you say, something can be completely technically accurate but it's all over the place and the lines are all crossing and you can't tell which line that label is for if it's got a label. It's always nice to label things in a diagram, or it's just acronyms and you can't be sure actually what those acronyms mean. It can be technically accurate without allowing people to actually understand it.

Iif people don't understand the diagram, if they're the people who are trying to make the decision, then they're either going to possibly make the wrong decision or just refuse to make that decision for you. And if they're the people implementing it, then they're either going to be asking lots of questions or they're going to probably implement it wrong. And when are you going to find out that it was wrong? When it's going to take time and money to put it right. Or maybe you aren't even able to put it right and it just has to go into production as it is.

Gregor Hohpe: Yep. And I think we've both seen that...

Jacqui Read: We don't know that situation.

Gregor Hohpe: ...more times than we would have liked. Now, one of the fun things about patterns is that patterns are not cast in stone. They're not, like, always true rules, they're not axioms, right, that always must be true. So there's always, and Martin Fowler even said this, right, for a good pattern, there's always a case where the pattern doesn't apply, right, because otherwise, it'll be like a ground principle or axiom or something like that.

So I wanted to pick on an interesting one that you slightly mentioned in passing, and that's mixing the levels of abstraction, right? And it's one of your patterns of what is an anti-pattern, right, to not do that. Now funnily, I like mixing levels of abstractions because the whole architect elevator is about right, here's the high-level stuff, and here's the detailed stuff, and I try to forge a connection. So is there, like, a saving grace? Like, can I make a valid excuse that sometimes it's okay to mix levels of abstractions, or am I banned from drawing those pictures?

Jacqui Read: I think there's always going to be exceptions to rules. And I think if there's a particular message that you're trying to show people and you're showing it in a way that that audience is going to understand it and it needs you to mix those levels, then yes. I'm certainly not saying that people won't ever need to do these things, because as you say, otherwise it's not really going to be a pattern, which is something that is generally the right thing to do.

But I think it's important to understand that there are small things like that all the time. So if you look at, say, a C4 model diagram, like you mentioned earlier, if you look at the context level, you will have, say, your system in the middle normally, and then you'll have other systems around that you interact with. When you then go down to the container level, which is the next level down, that container may also interact directly with some of those external systems. And so that external system looks the same on both of those diagrams, typically. You could say, "Oh, actually, no, I'm going to break that down so it's a particular API in that system," but typically it's that system. You could say, "Well, that's mixing your levels of abstraction."

But it kind of is and it kind of isn't, because you've got to think about what detail you're showing to people. So if you're saying, "Okay, yes, this is talking to this system but that detail of breaking that down isn't important," or, "We don't actually even know that detail, this is a black box," then you can't show the different levels of abstraction, can you? So yeah, there's definitely going to be exceptions to the rule.

Gregor Hohpe: Relevance is sort of the keyword and is one of those funny words, like appropriate, right, like do the appropriate things, like, show the relevant things. At the same time, I do entitle myself to the word relevance because that's what architects do. We decide what's relevant and what isn't. That's our human judgment. So I would say if there's something very relevant in terms of showing the big box but also showing which part inside that big box maybe provides the interface that might be relevant, and then mixing the levels might be natural versus if there's, like, a random line of C# code in the context diagram, that's maybe a little bit questionable.

So where I like the patterns and the anti-patterns and documenting this as patterns as opposed to as unbreakable rules is that, yes, you can do this, even if it's written as an anti-pattern, but you know you're sort of on your own, right? It's sort of a little bit like the safety barrier is off. So that means a couple of things. A, probably visual clarity becomes even more important, right, because the last thing you want is a messy diagram that goes across levels. So the anti-pattern still sort of tells you that you're a little bit out of your comfort zone. Yes, you can do this, but be extra cautious. And I still think this is very valid advice, and it sounds like it doesn't go against the spirit of the book. Very cool.

Jacqui Read: Definitely.

Enhancing Communication & Accessibility in Software Design

Gregor Hohpe: So I wanted to ask you a few things, sort of as we're almost wrapping up. These conversations always go very quickly, right? There's no way to talk about 300 pages in 40 minutes. I was curious whether you have a favorite pattern or what I call a favorite unfavorite, like one anti-pattern that people do all the time that really annoys you or one that you think is really nice that you like everybody to get correctly. So are there some favorites or favorites among the collection of patterns?

Jacqui Read: Well, one of the sections that I haven't mentioned so far is the accessibility chapter on the visuals. That's something that when I talk about it in workshops and talks, people always say, "I really never thought of it like that. I hadn't considered how someone who is neurodiverse or autistic might understand what I'd said," or a lot of people have never even considered things like color blindness because it's only 4.5% of the world's population. But it actually affects more men than women. So in the technical industry, you're more likely to come across someone who's colorblind than in other industries as well, at least at the moment. Hopefully, that will change one day.

But people just don't really think about these things. And so those are some interesting patterns in there to help people to actually make their diagrams accessible to everyone and not just, "Oh, this needs to be for technical people," or, "Oh, this needs to be for architects," or, "This needs to be for project managers." It's thinking about a different sort of audience. So I particularly like those.

Gregor Hohpe: I couldn't agree more. And one of our favorite social media platforms just a couple of days ago or so posted about event sourcing and event-driven systems, and the closing sentence was, "Oh, in my notation," what was it? "The state is always green, the events are always yellow, and the documents or the objects are always blue." And I was thinking exactly that. Like, what if somebody has a difficulty like a red/green, blue/green kind of weakness? And this will not work very well.

So, unfortunately, yes, so this is a favorite and an unfavorite at the same time. We see it ignored so many times but I think it's critically important, right? Do use another attribute, use different shades, a different intensity, different framing, use something else so you don't rely just on color and I can easily subscribe to that.

Jacqui Read: That's one of the patterns called don't rely just on color.

Gregor Hohpe: That would be sort of my closing comment on the chapter of patterns, right, the naming. It comes so naturally once you have a pattern book that your chapters don't have sort of, like, names like Section 2.3.4, right? But the name of the pattern is don't just rely on colors in a dialogue. You can refer back to those. And that is really a unique strength of the pattern and the pattern language that you can make them part of your spoken language and refer back to them.

Now, just like this Book Club interview, we are near the end here now. The book is all so done. So it's funny as software people we like to talk about agile and iterative, and book's still a little bit of a waterfall, right? They got to come out at some point and be published.

So what are the next things that you're working on now that "Communication Patterns" is well out the gate?

Jacqui Read: Well, the thing that I'm working on at the moment is quite an exciting new project. It's called the ACED model. And just like "Communication Patterns," it's been born with the mission of improving communication, but also with that intent of creating software that actually does what the customer and the business want it to do while also being evolvable because everything is always changing.

Kind of the intent, we're creating kind of a system. It flows from the context through design, architecture, and then eventually into engineering. It goes from behavior first into the structure. The ACED model is named after those different stages of that flow. So the architecture, context, engineering, and design. But, of course, it's out of order. We have to move them around to make it pronounceable.

So where "Communication Patterns" is very much tactical, the ACED Model is at that strategic level. And we're developing this concept at acedmodel.com at the moment. It's very interesting, very new. So if anyone wants to have a look at that, have a look.

Gregor Hohpe: Oh, very cool. I always say once the book is printed doesn't mean the ideas stop coming. So it's great to see that you're taking that topic broader and making that into a framework. Well, it's been such a pleasure, Jacqui Read, to talk about your book. I always call this the "Fahrenheit 451" effect, where there's the written book and there's the person that represents the book. So I love talking to folks who have written a book, and if you look at their work, you can also always see a little bit of their character and their voice and their nature inside the finished work. So it's been a great pleasure chatting. And to all our viewers, thank you for tuning back into the "GOTO Book Club," and hope to see you another time. Thank you so much.

Jacqui Read: Thank you.