Breaking the Architecture Bottleneck

The Problem: Traditional Architecture as a Bottleneck

Marit van Dijk: Hi, my name is Marit van Dijk. I'm a developer advocate at JetBrains, Java Champion, and I've worked in it for 20 years. I'm here with my friend Andrew.

Andrew Harmel-Law: Hi, I'm Andrew Harmel-Law. My pronouns are they/them. I'm a principal at ThoughtWorks, which means I'm a consultant. I get to work with lots of different people, doing lots of different cool stuff and I keep forgetting. But I need to mention I wrote a book as well, which I think we're going to talk about a little bit. So the book is called Facilitating Software Architecture, because what I do a lot is help people do software architecture.

Marit van Dijk: Right. So tell us a little bit about your book.

Andrew Harmel-Law: The book comes from frustrations where I'd work with loads of different clients and we thought we'd come in. Lots of people will have heard the full works. A customer would have a problem. They would say, oh, we'll get talks and they'll come and help us solve the problem. And the problem was typically around software.

So we would come in with loads of different things like people are awesome developers and loads of XP practices like comparing programming and TDD and CI/CD and all these kinds of things. And so we do all of this work to build really good code, to set up really kind of high performing teams to, just kind of build the product that the, that hopefully the client was looking for the product, people were looking for help.

Because we were good at it and we would, you know, the clients would we would get better and better so that the teams would start going really fast. And my job on these projects was typically to be an architect, maybe an architect on my own, or me as a part of a team of architects. And I was realizing that there's all of these things we figured out to make the code get into prod faster, and to just get out of the way of the code, you know, between get out of the loop, which is like in the developer's head down into code, into the compiler, and then, you know, and then deploy down to prod that bits quick these days. But the bigger picture.

Marit van Dijk: Or something, if you have a good CI/CD, etc..

Andrew Harmel-Law: So I know, but like the architecture bit where someone would be going. But this is the bigger picture. This is where it's all going. I was getting stuck more and more. I was becoming a blocker. So everyone else is doing all fast, right?

Marit van Dijk: So architecture is actually getting in the way of getting software to production. Exactly.

Andrew Harmel-Law: But at the same time, because everything's more split up, because teams are like more teams are firstly more autonomous or self-managing. So therefore the idea is, is we're getting as much out of the way of the devs and the rest of the team or writing the code. We're trying to get as much out of their way. Therefore making sure that all of these different independent people who are working on their little independent chain sets and pushing their stuff into source control, we need to keep all that lined up kind of headed in the same direction. So architecture is actually super more important.

Marit van Dijk: Right?

Andrew Harmel-Law: Because everybody's more empowered.

Marit van Dijk: But you're hurting the autonomous teams more than the ivory tower top down. Exactly. Right.

Andrew Harmel-Law: Okay. Therefore I was like one reaction would be to like kind of command and control and just get in people's way more. I did it.

Marit van Dijk: Because developers love that.

Andrew Harmel-Law: You get really good feedback from developers. They're like, this is not working. Right. So we know what we're doing or, you know, whatever you're getting in our way. That was true. So my big thing was, is there a different way of making sure that the right decisions are being made, that you're getting the software to go in the right direction, but without having to go through? Typically, in my case, the mind of some kind of straight, white, heterosexual, hierarchical dude who tells you what to do in an ivory tower, right? In the cliche, it's not necessarily a cliche, because in my experience, people in the ivory towers pipe in there as much as everyone thinks they love it. But it has to go through this loop of those people telling everyone what to do. Yeah, and that just doesn't work for a different reason.

Marit van Dijk: And in my experience, also, I've worked in companies where it felt like the architect's job was to say no. Yeah, yeah. Like, hey, we need to connect this application with this application and need to go through this application in the middle. But you can't because that has been on the decommission list for ten years, and you need to build it in the replacement system that is not there yet. We haven't even started working on it. And for legal reasons we need to connect these now. 

Recommended talk: Facilitating Software Architecture • Andrew Harmel-Law & Sonya Natanzon • GOTO 2024

The Solution: Facilitating Architecture Decisions

Andrew Harmel-Law: So exactly. All these things I'm listening to are the kind of things we get involved in. In the past I would try and figure out how to navigate through that. And then I would try and figure out how to communicate my way of navigating it through it down to multiple teams, which is hard. And then at the same time, architectures are evolving, right? So I'm not doing it once. I'm doing it over and over again. Exactly. Double hard. So then I was like, instead of that, what if I facilitate the collective, the individuals or the teams? Because we're really thinking of things in a team like a kind of unit that no, not, you know, not individuals but teams.

If we do that, then does it work? And so I tried a bunch of experiments and it turns out it does. So you still have a lot of stuff to do, but you're not doing software architecture. And that's the title of the book facilitating it. Right. So you're still making people think about trade offs. You're still making people think about the big picture. You're still making people think about the relationships between my team and your team.

Marit van Dijk: My application and your application. 

Andrew Harmel-Law: All of the tech stacks, all of the stuff. But instead of it coming to me to say yes or no or to pick things, I would be facilitating you and your peers and everyone else and like trying to balance, maybe not even balance, but just make everyone aware of the conversation so that people who want it to do one way would have people who want to know the way, and then kind of bring those conversations together. So that's kind of the thing.

Marit van Dijk: That sounds super interesting. I'm thinking about situations where we had architects who needed to decide where a certain piece of functionality would end up, would it be in this application or that application?  I don't quite see how that would work. Maybe in the examples that I have in my mind,  the teams would have to negotiate that amongst themselves. So then how would you facilitate such a decision?

Andrew Harmel-Law: So it's a really good question. So there's kind of a few, there's two things that there's three things that triggered the idea. There are three things that triggered that idea of the book. And so the first one is a quote from Bruce Mallon, one of the famous architects who I really admire. And so Bruce has this long post called, I think, are architects necessary?

So the spoiler alert for the article is, yes, architects are necessary, but Bruce talks about what architects do and comes to the point that the key role of an architect is to make sure that conversations are happening. Now. You don't need to be part of the conversation. You don't need to be like interjecting into the conversation. But what you do need to know is that the right people are having the right conversation at the right time with the right information. So maybe that conversation is happening. So maybe you're speaking to your team. You know, your team is speaking to another team about where this feature goes. If I'm an architect and the whole conversation sounds perfect and sensible, and everyone seems to be going in a sensible direction and bouncing all of the right things for me, I could technically, I could leave it alone.

Marit van Dijk: What if both teams are like, well, we understand the company needs this functionality, but it should not go in our application and the other team is also it should not go out, you know. Exactly. So therefore someone is going to have to be okay.

Andrew Harmel-Law: Precisely. And so this is the thing. The big thing is that, what you end up doing as an architect is instead of telling people what you do, well, come to why that's a problem. You could your default reaction is I will now use ask you privilege, right? Yeah. You stop it. You do it. I don't care that you think it sucks and you, like everyone, hates it.

Marit van Dijk: And that's always going to always be.

Andrew Harmel-Law: What you want to do is, is bringing to. And this is. So I used to start by offering advice because basically the fundamental thing in the book is called the advice process. So you don't seek permission, you just seek advice. And you need to seek advice from people who have expertise in the matter and people who are affected.

Marit van Dijk: And who is the, who is seeking that advice? Is it the architect or the team?

Andrew Harmel-Law: Who's making the decision? So what typically happens is and this is something I learned from speaking to Toronto, Auckland who like to study socio technical systems, right team level decisions or decisions which primarily belong to a team will come from and be decided by a team. But you'll speak to your peers who are affected.

Marit van Dijk: Exactly. You might speak to other teams who have done a similar process or used a similar technology, etc..

Andrew Harmel-Law: Or you're changing their API so they I have a ticket on the backlog, or it'll be something like not on a higher level, but like in between the individual parts, right? So therefore I'm just like you said, there might be no best place for it to go or correct place for it to go. Right. So there'll be a trade off. There'll be a bunch of stuff. So typically an architect, a systems architecture, a solution architect or someone, whatever the word is in the company, they'll come along and trade off things and say, right, I think I should go here, but I've listened to this team, I've listened to this team based on the tech strategy of the company, which is hopefully clear and on our cross-functional or we call them cross-functional requirements, nonfunctional requirements and our like investments in this technology.

So I've been in clients where everyone has wanted to do something exciting with a new product like some other provider. But the answer has been no. NewRelic  is who we've just paid for a three year license for. So irrespective of the fact that you've all selected this new cool technology, it's going to be you.

Marit van Dijk: Unfortunately.

Andrew Harmel-Law: Yeah, I mean, not it's unfair to pick a New Relic, but New Relic seems to be very successful and everyone picks it up all the time. So you'll kind of come in, but your broker, those kinds of conversations and what you want to do is the key thing is to remember, remind people that there isn't a right answer or a wrong answer or a best solution. What there is, is, is a decision which seems to fit right now, which is what does a good for right there a decision in a point of time based on all of the information we have.

Marit van Dijk: Do we need to explain what an ADR is?

Andrew Harmel-Law: We do this because I get this, I did a talk about ideas once and you often said you didn't explain what is. So an ADR is an architectural decision record. So a single decision which is a choice, a selection from one of a different set of course of options. So you might be like we could do this. This is our problem. Here's our context which is in the ADR we can do either A B or C. Here are the pros and cons of the pros and cons b pros and cons of C.

Marit van Dijk: And therefore we have selected.

Andrew Harmel-Law: And we select one. And when you do the advice process you write the ADR. And then you seek advice from people who are affected. So other teams and those with expertise architects infosec. If it's a bank you'll speak to the regulator.

Marit van Dijk: Compliance.

Andrew Harmel-Law: Compliance case. Right. So you bring in all that stuff and you record it on the ADR. So you get a nice record of the thing and that's how you do it.

Marit van Dijk: And that is also super useful in the future because you might end up working on code bases where none of the original developers are still there. And you find the code and you're like, but why? Why is it like this? And now you can go back and at least okay, because at the time with this information, there are the...

Andrew Harmel-Law: You can see what people knew. You can see what the priorities were. You can see because it's missing what they had no clue about. So you'll be like, why did they not?

Marit van Dijk: You know, of course, in hindsight, now we know that that was about this, but we didn't have that. And the best decision that we could have at the time. Precisely.

Andrew Harmel-Law: Right. Precisely. And this is what's interesting. So there's another quote that triggered some one quotes, three quotes triggered the book. The first one I've just mentioned is to make sure the right conversations are happening. The second isn't necessarily a quote, but it's an experience of open spaces. So seeing open spaces is like a way of organizing conferences, where if you do as little as possible and get out of people's way, if people have a shared goal, do we.

Marit van Dijk: Need to explain open spaces to people.

Andrew Harmel-Law: Very quickly? So like this, very this, the open spaces are literally like a forum and a timescale. And the rules are, whoever turns up is the right person. Whatever happens is the right is the only thing that could have happened. When it's over, it's over. And there's another law, which is the law of two feet. So people proposed sessions and sessions happened. There's no lecturing or anything. It's just people sitting around in circles talking about things. If you don't like a session, you can get up and leave everything else.

Marit van Dijk: And if you're adding or getting value from that session, or you're just tired and you need a break.

Andrew Harmel-Law: Actually.

Recommended talk: Reading Code Effectively: An Overlooked Dev. Skill • Marit van Dijk & Hannes Lowette • GOTO 2025

Three Key Influences on the Book

Andrew Harmel-Law: And so this I learned from that, like getting out is exactly if you get out of the way, it's a miracle what happens. So that's the second thing. But the third thing and this was what kind of the first two were cool. The third one was haunting. So Alberto Brandolini, who's the famous Italian, is very enthusiastic about the boards he's asked to give to me.

Creator events storming. So he had a tweet, which I'm sure Alberto just thinks amazing thoughts all the time and just tweets them out. But the one that struck me for years was it's the developers assumptions that make it into prod, not the diagrams on the wiki. Yeah, not the high ideals of the product manager, not what the CTO thinks.

It's what turned into code. Right? So the interpretation of those pages on the wiki and the and the press.

Marit van Dijk: Release might not be what was originally intended. It's the mental models, the mental model of the developer that makes it.

Andrew Harmel-Law: This was the thing. So on top of all of this stuff, I am trying to run around. And so this was my thing. Even if I do great architecture and it's the best decision and it's done well and I've documented it beautifully and it's all an idea if I do it and then fumbled a bit where I go to speak to the dev and say, can you code this? It's irrelevant.

Marit van Dijk: The other thing, sure, that they actually understood it in the way that you intended it, because communication of course goes totally both ways.

Andrew Harmel-Law: The other key thing is, even if I do communicate it well and they do exactly like I say, they then push it down into prod, right? They push merge it to master or merge it to main, and then it goes down into prod and then immediately gets deployed. The reality of running code is going to rapidly tell you whether my decision was a good one or bad one, or whether customers whatever, right?

Marit van Dijk: Production is where your code meets reality.

Andrew Harmel-Law: This is the thing. That none of this makes any sense until it's been down running, being used by someone. Then you close the loop, right? What you got was continuous deployment or TDD or pair programming. They're all feedback loops, right? Yes. So you close the feedback loop and you get this valid thing. And the shared mental model, the kind of the tightness on it.

Like what I saw, what you know, doing the right idea is what you thought right in the code. Then we push it down to prod the customers in the environment and the traffic and stuff. Think about it. Well, then we get that back and we can.

Marit van Dijk: Whether we took all of that into account when we made all of these decisions and wrote all of this code, do we actually properly understand our customers, their data?

Andrew Harmel-Law: All that stuff, all of which. And so then if you're thinking, right, if I'm going to make a decision, ideally I'd want to take all of that into account. So you do and you can do, which is what this kind of approach does because it doesn't just mean it has all has to come all. For me as an architect, it can come from me, from you, the marketing person.

The best thing I've seen at the moment at my current client is they get product management to offer advice on ideals. Product management is like, we know these two are technically awesome and you're all very excited about them, but this one's the one that's going to deliver more value. So the Pro for option three, which everyone hates is like Java eight or something. They're like here's an existing Java eight system. You could push this to prod very fast, which doesn't mean it's right, but it's like it adds all of the right. So then you've got your thing. So all of this kind of like closing the loop on this mental model because this is what interests me most about software. So I don't get to write code anymore for various reasons.

Number one, I was probably because I'm a social worker. I had to be a certain level of goodness at code, but I'm probably on most of the projects I work on. I'm the worst developer, which is why I do the architecture and everyone else gets to write the code. But what astounds me is that I don't know how anyone ever managed it, but we do manage as a collective because nobody builds software on their own these days, right?

Exactly. Apart from small open source projects, which everyone depends on. But like, we build like teams of 30, 40, 50, 100,000 people build software, which has to go through a compiler and get into production and somehow do a job. It's a miracle to me that any of that ever works ever at all. So there must be.

Marit van Dijk: Well, those are the two states of a developer, right? My code doesn't work, and I don't know why, as my code works and I don't know how I can use it.

Andrew Harmel-Law: And this is the thing is like, how does that so this is what I want to think about next. I am posting this book because writing this book and getting out of my own head and then starting instead to like, like with the open space thing, you don't create the conference, you create the space for the conference. So with architectural facilitation, you don't create the architecture, you create the space for architecture.

People are making bad decisions. It's not that dumb. It's because you haven't given them the skills to make the best decisions, right? Or you haven't listened to them because maybe it isn't dumb, but you just think it is because you haven't discovered what's going on. So stepping back and making more of a space for this shared mental model, which is important for the code.

The other thing that's interesting to me is, it's not just the code now because we don't, like, do a lot of designs and then code up for three years and then deploy it prod and we do like stop it. Right. So yeah. Exactly. And like so we iterate and stuff. Everything evolves. So how we build this thing which turns into code and then evolves over the course of time and people can still understand then it can be like.

Marit van Dijk: Helps a lot. Hopefully sometimes they can.

Andrew Harmel-Law: And this is the thing to that kind of because that's the architecture, right? The architecture isn't. It's like when, when you know, you look at this is why architecture is a bad word. It's not like one big gigantic building that someone drew on a big piece of paper. And then we built. Right? It's more like a city with all of this stuff, and it's growing in the neighborhoods, changing and all this stuff's kind of coming and going.

Marit van Dijk: Even the building that you built once, you know, you might strip the outside and rebuild it again or you might do. Yeah. I want to say refactoring, remodeling. Yeah.

Andrew Harmel-Law: But it is kind of like refactoring. Right. So that's so interesting because Kevlin, he talked about this and he's got a really nice slide which I want to steal where he's got a photograph of two houses which are built with the same design, you know. And then he's.

Marit van Dijk: Gonna ask him for his slides by the way.

Andrew Harmel-Law: So and then like he's like then like ten years later, there's two photographs of the same house. And like, different people have lived in them. And so they look totally different. That's like this. Yes. The point is code like literally that's what we're doing.

Marit van Dijk: Well only if we live in it, you know, like, is this the final code? Well, you know, once we turn it off, that is the final code.

Andrew Harmel-Law: But you never know these days, like, I mean, I know we do decommission stuff. We decommission stuff a lot less than we ought to, I think. But, what's interesting to me is. And which nobody seems to talk about, but I'm more and more interested in if this is where because code is made out of thoughts or like what we think or it's where we live, it's not just what we I know we build code where people do jobs, but as developers when we're trying to, you know, I'm trying to come up with an overall architecture.

You are trying to code up pieces of the architecture. The QA is trying to test bits of it. The product manager is trying to drive everything in a direction where they think it's going to like serving, customer needs and stuff. But we don't do that once and then forget about it. We're doing it over.

Marit van Dijk: We do that all the time. We're adding in like we're learning things as we do it. We're getting new information. The world around us changes. The customer's needs might change. A competitor might do something that makes us need to change direction. Then we mentioned, you know, dependencies that we use might change, especially if they're being open source dependencies built by, you know, one person somewhere who might decide to go do something else with their lives.

So, all of these things might change at any time while we.

Recommended talk: Keep Your Dependencies in Check • Marit van Dijk • GOTO 2023

Andrew Harmel-Law: We're trying to just stay on top of stuff, and and I think this again, I've done a talk about this, like, like you said, right. People do. We get paid very well to write software. Some people get paid better than those. But both, you know, compared to lots of jobs, we get paid a lot to write software.

But one of the things I'm aware of, like pissed off, like a lot of us, not everyone, but most also do X. We love it, right? So this, this weird thing where we love writing code, we love doing stuff we want and like in my experience, it's not the only reason why it's good code, but if it's got a good architecture, it's where you like being.

Being a developer is where you like to continue to write code. It'll make sense when you look at the code. And this is what I kind of want to think about. Maybe my next talk is with them.

Marit van Dijk: And so you're right.

Andrew Harmel-Law: You know I'm not wrong.

Marit van Dijk: You heard it here first.

Andrew Harmel-Law: I wasn't. But I do want to like, pitch because I do want to know about the whole like, if there is this longer term relationship and a group of people need to live in a code base and share a mental model and grow and change and stuff. And one of the ways of describing that is to like to use the word architecture.

That to me is super interesting. And now we know about sociotechnical things. So therefore all of the social stuff also has an impact and all of that kind of thing.

Marit van Dijk: That's one.

Andrew Harmel-Law: To me, super.

Marit van Dijk: Interesting. That's one of my favorite things is when you have a team that works well together and you're working on a code base and you kind of have a shared mental model, you have a shared history, and it might become difficult if people leave the team or if new people join the team. I saw a tweet once that said teams are immutable data structures. You know, if someone leaves or you add some, you have a new data structure. And that is kind of true because it might change. Yeah, for lack of a better word, that vibe of the team. Yeah.

Andrew Harmel-Law: Totally does.

Marit van Dijk: You have to kind of renegotiate. You have a new teammate. Okay. This is how we've always done things. A new teammate might come in and start to question things which might be less pleasant, but might also be super useful. And you can learn something from a new person on the team.

Andrew Harmel-Law: Like so this is and I completely agree. And that's why we don't talk about that. Like we talk about the consequences. All right. So we talked about Conway's Law. It's like the structure of the system or the information structure of a system will be, will be, will parallel the information parsing structure of an organization, etc.. And then we do inverse Conway to like try and reverse engineer.

But the step before that we don't really talk about and this is an interesting thing. So for like one of the later chapters of the book, architects kind of love the kind of top down, forward passing type stuff. So I went and read < a href="https://amzn.to/3Urefj3Christopher"> Christopher Alexander's book. to go to the source of patterns And there is loads of stuff which is correctly in software for various very valid reasons, which are all about these patterns.

Go down here and then you have a pattern and within it it contains other patterns within that pattern. It contains smaller patterns, which is completely valid. What I didn't realize is. So I reread the book. There's a whole bit in the book about the process of repair. So there is this kind of top down, big to small communication flow, right? So like big patterns or the big context, a big decision like someone decides to use Java eight, right? That's going to impact loads of other stuff.

Marit van Dijk: Then that comes to what kind of dependencies do you use.

Andrew Harmel-Law: Exactly.This thing, the knock on knock on knock and then which cloud you can use. Right. So loads of stuff happens but there's also something smaller but more diffuse. There's lots of little voices and the little voices are people complaining that Java I can't do all the things that Java 23 can do. Right. And that might be.

Marit van Dijk: It might be able to do the same things, but it's going to be harder on the developers at some point. You know, dependencies might no longer work with Java 8. Spring, last year I think, updated to you have to be running Java 17. Exactly. But also you get all of the nice language features that make Java these days so much nicer than at university when we  started ten years ago.

Or, you know, 20 years ago when I first started learning Java. And why wouldn't you want to have  nice things?.

Andrew Harmel-Law: The thing, it's like, that's why I think we ignore from an architecture perspective this. Which is why I want to think about these two. We still think it's very even me. When I was writing the book, I was like, oh, it's all mostly top down, but there's all of this stuff, you know, that's a feedback loop, which isn't the feedback of the code in production.

That's the feedback of the experience of the people living in that place, which is the people writing the code. So yeah, they'll be more aware of stuff there and you'll see it. And this is what Christopher Alexander talks about in the book is like, that's the process of repair. So you're not like tearing down the, you know, the roof of your house and putting a new roof on.

But you might like, build an extension with a different type of roof, right, with solar panels on it or more he, he, you know, so you'll end up with this patchwork of stuff. There's like, oh, this is exactly what we end up with, but accidentally, not consciously. So now what I want to think about is like, if you could, if you could at least number one, acknowledge this happens and then do it more consciously.

So even ThoughtWorks has things like bounded by, which is a blip on the radar from a long time ago. I think it's even dropped off the radar. But its big point was don't say we're going to use AWS for absolutely everything because someone will come along. A data scientist typically will come along and say GCP is better, right?

So then you're like, okay, we'll use AWS for everything apart from all the data stuff, because GCP because the data scientist says it better. And then I've been another client where they're like, we'll do all of this. But one thing we want to use is, you know, a high performing part of our architecture, which is some secret sauce, needs a certain chipset which isn't available on Amazon.

So we'll put it on Azure.

Marit van Dijk: So this or there's companies who are like we want to be agnostic. We don't want to put all of our eggs in one basket. So we're going to use all of them.

Andrew Harmel-Law: Yes.

Marit van Dijk: Yes. Now I have to learn all of them.

Andrew Harmel-Law: So this is like and this is what I want to figure out is how I can because it's so cool but the reason the book works I think in the recent past me anyway, is I mentioned there's a whole big book about facilitating software architecture. Fundamentally, it uses the advice process, which anyone can decide as long as they seek advice.

That's it. You can write it in like a single slide, and then the rest of the 462 pages of the book are like, okay, when you do that, this is what happens. I think.

Marit van Dijk: People should still read the form.

Andrew Harmel-Law: Website. I can tell I found a record that I should because there's a blog post which is like eight pages long or something, which is the summary. And then it turns out you can use a book blog post on Martin Fowler's website to pitch a book to O'Reilly and go, I think there's another 400 pages of that. But the core is very similar.

Marit van Dijk: That's how that happens. Yeah.

Andrew Harmel-Law: That's so, that's my sort of work of privilege. So is that it started Twitter and actually then it turned into an article and then it turned into a book. But fundamentally it's just like so decisions are important.

Marit van Dijk: Continue to rant on social media. I might end up accidentally writing a minor.

Andrew Harmel-Law: Blog post on them.

Marit van Dijk: Like, think it's just.

Andrew Harmel-Law: Because of my private site? Sometimes you invite other people, but. So that's like, that's the core thing. But I think there's this other kind of listening, the habitability of code bases. Yeah. You know, if we architect homes, we don't architect homes because they are efficient, you know, places for human robots to live. We architect homes. And this is the whole part of the Christopher Alexander thing is like, robot equals, but there's like, there's a magic or a wholeness or something when you get a building or a neighborhood or whatever, when you are in a room, when you get it right.

Right. Yes. And I think and I want to do a talk about this and Gregor, I hope you and I were talking, chatting about it on LinkedIn. I probably pronounce his name wrong, but anyway, Gregor, we keep forgetting that. But then you see people writing code and the joy, like you said, not always. Half the time it's like completely driving around the twist.

But when it's working and when you're working with your colleagues as a team, yes. It's magical. There is that thing there, right? Which we don't talk about enough. And I think, yeah, it's not just a cool thing. I think that's important. Signal to pay attention to.

Marit van Dijk: It's when you've been on a team that works really well together, then it's really hard to accept teams that don't. Yeah. Which is my problem because I've been on the former, working really well together. But that does remind me. I kind of wanted to circle back to you. Likened facilitating architecture to open spaces.

Andrew Harmel-Law: Yes. 

Recommended talk:Navigating Complexity with Systems Thinking • Diana Montalion & Andrew Harmel-Law • GOTO 2024

Implementation Challenges and Organizational Culture

Marit van Dijk: Which really works for me having been to Open Spaces. If you haven't recommended it, but the people who go to open space kind of self-select and are the people that are interested in doing it that way. Yeah. The people who work on software teams don't always self-select. And so I wanted to ask, are there specific things that the people who work on those teams need to have or to be? Is it certain cultures where this works or doesn't work?

Andrew Harmel-Law: Yes.

Marit van Dijk: Because I can also imagine companies, especially if it's very hierarchical, if they have to cover their ass all the time where this would not work or I have a hard time imagining working. So these are some of the preconditions.

Andrew Harmel-Law: So it is really good. So the caveat number one, there are less preconditions than you think. What you need to do is so this is literally the last because the books are in four parts. The first part is like here are the basic rules. The second part is you'll probably need some of these extra things. Please don't do all of them.

That's like, do you know doing agile, you end up doing all of agile, right? Like just do the bit you need. The third part is it turns out decisions are all related. The stuff I was talking about, Christopher Alexander and all these things. The fourth part is about power dynamics, leadership and building a safe environment within a yeah, within a hierarchical organization. Because I am not naive enough to think that everyone will magically become one.

Marit van Dijk: Exactly like coding. I think this is what I was going for. I think you have to have a safe environment where it is okay. Yeah. To, you know, openly discuss. We think, you know, this functionality should be in your application or in my application. And also to honestly say why you think that rather than have to guard that because that you're missing out on information and you're not going to get the best decision.

Andrew Harmel-Law: Yea. And be wrong and fail and like work as a team.

Marit van Dijk: Without, you know, getting smacked upside the head and fired or promoted.

Andrew Harmel-Law: Exactly. And that's why the leadership thing is there because. So you need leadership because you're going to transform and change. Right. But it turns out that if you do leadership from top down or even like servant leadership, which is pretend bottom up in my opinion, still top down, what you want to do is all of these things is the word facilitating keeps coming back through it.

It's like if you're the person making it happen and this goes back to open space, you can't like an open space into being. You just need to get out of the way. And this is so, if people are interested. Actually, the Winter tech Forum is the first time space ever went to as the tickets are open now and it's in Colorado in May. I think.

Marit van Dijk: We talked about that.

Andrew Harmel-Law: This is amazing. So like Bruce Eckel runs it and James Ward run it. But what I learned from Bruce is and this is in the book, Bruce realized that the less you do, the more it works. So, Bruce, every year I'd go every year and Bruce would basically have a list of what I'm going to not do this year.

Bruce last year, like some pretty much Bruce books, the charter school where it happens. And I think he books a yard where there's dinner. All right. And I think it's maybe not in the charter school anymore. It's probably not there this year. But he does two things. And then and then he posted the posted date on his website. It's nice implicitly, basically, that he stands back and you're like literally.

And then it organizes and people come together and there's like 2 or 3 people who've been there before and they all explain it, but even the people now, so when I start coming a few times, I'm like, oh, I'm now taking over, so I should step back. So this kind of wave of people slowly steps back.

Marit van Dijk: But that also, again, only works if the people are self-selecting. So understand this and continue to do this.

Andrew Harmel-Law: And so this is the thing what I think is it work it work broader if and this is what I've seen. And so this is because I checked, the first company I tried this with was a client during Covid. So I've done bits of experiments, but I tried it with a.

Marit van Dijk: Covid brought extra challenges.

Andrew Harmel-Law: And so this is like, we're like, if we're going to do it, let's just like, while Covid is happening, let's try this experiment. So they've been doing it for four years. So people said, oh, it'll only work if it's full of social workers or lonely workers and a million reasons why it should work. Because, you know, but it was like they were just a regular company building insurance software. It was like they were just regular human beings doing a good job. Not like, you know, I think seeing it and all these kinds of small things.

Marit van Dijk: People who want to do a good job.

Andrew Harmel-Law: And this was in.

Marit van Dijk: A safe space.

Andrew Harmel-Law: It's a safe space. So that was the thing. That was what? So Pete Hunter was the person who did it. He let it. The CTO above Pete, and the CEO as well. That's what they did. They gave the permission to do it up in other places where you don't have to go that high. And this is what chapter three is about, like creating bubbles because sometimes.

So when I was a previous consultancy for I was it's all works. The team ran and I talked about it. The team ran in a kind of self-organizing way. Yeah. So the important people like the HR teams were aware that I was doing this because otherwise it would have been a bit of a political disaster. But from the outside, and this was chapter 17, as long as the team looks like it's writing software and it's shipping stuff and it's good architecture and it's going, nobody really cares because this is the opening chapter 17.

Marit van Dijk: And software.

Andrew Harmel-Law: People are different cultures anyway, right? We don't. We've worn t-shirts and jeans to work a long time before everyone else started doing it. Yeah. So it's kind of like find. And this doesn't mean everyone but my experience is the more you trust people and the more you help people learn to kind of build, build that trust and be wrong and learn from others.

Marit van Dijk: Yes.

Andrew Harmel-Law: Again, if someone is smart, like instead of, you know, I do, then this again is in the book. Don't coach them to be better. Help them to coach other people who they're like, well, that person is not very smart. I'm like, well, how can you teach that person to be smart? You actually know things because of ten years more in the.

Marit van Dijk: But also one of the things that I really like is that we all know different things. And again then we go back to one of my favorite teams that I worked on. Everybody brought different things to the team. And just because, you know, you might have ten more years of experience than me, doesn't mean that I might not know things that you don't know.

And if you can tap into that and and also discuss the team, like, okay, this is what I know really well. This is maybe what I want to learn or grow into and then help each other. And then you become more than the sum of the parts.

Andrew Harmel-Law: 100%. So like this is like again, there's a massive diversity thing, but I'm like an ODI is now a dirty word. The teams, the best teams I've worked in, are where we are not all like each other. When I've been in teams like you're like, it's a diff. Rich runs. People read things including and this is this person in the book, he's called Rita because Rita was my editor.

So Rita isn't the software architect, but Rita would ask amazing laser focused questions. And there's a person on a young developing team. And I have worked with young developers like this. I've and I've learned from developers who were good. And now I've started coaching developers to be this confident. And it does take coaching right. You don't need to know the answer if you.

But if you're like if it should be clean, simple, you know, like everyone's striving for simple, clean, beautiful, elegant architecture. That means everyone in the team, not just like the rocket scientist person who's like, you know, got a PhD and, you know, we used to work for seven of the Faang companies and all this kind of stuff. Everybody in the team should be able to understand it, contribute to it, maintain it and evolve it.

That's part of the new thing. And if you can enlist the person with the least experience to go, this is not as clear as it should be. And super.

Marit van Dijk: Yes.

Andrew Harmel-Law: So you want.

Marit van Dijk: So and so again also the team that worked really well I was able to know they had an open culture of asking all the questions because your question might trigger something that we haven't thought of. So and also the culture was you build it, you run it, you love it, so you run it in production.

That means that, you know, if you wrote this change and you're going on vacation and next week we have an incident on that change, I need to also understand the changes that you made to the code base, so that I can support it when you are not there or, you know, whoever might be there 100%. And that's really important.

Andrew Harmel-Law: Like Brian code. So like if your best friend has to fix it or if you at 3 a.m., I have to fix it.

Marit van Dijk: We have this trope to imagine the person who has to maintain it is like, you know, a psychopath. I don't like that. I want to change that. To imagine that the person who might be maintaining this is you or someone that you like. And I'm going to assume that you like yourself, you know, have some empathy towards the people who have to maintain this software, I think.

Andrew Harmel-Law: And again, that comes back to code like this is because I'm a superfan. It's true that the two hardest things in software are naming and cache invalidation rights.

Marit van Dijk: And off by one error. So we did this interview.

Andrew Harmel-Law: But talk but but but and it's true. Like naming like and but this is the thing naming is hard but the more you involve more people naming gets easier. Which is implicit in Eric Evans's book. And in all of TDD, it's like, don't come up with a new name co-created with the domain expert, right? So I already figured it out.

Marit van Dijk: It's going to make your communication much easier, etc. 

Recommended talk: Dev Harmony: Communication & Proven SRE Practices • Liz Fong-Jones & Marit van Dijk • GOTO 2023

Andrew Harmel-Law: And all and all of this stuff. So this is and again, this is why I think there's at least one more book. There's a simple kind of core which I've expanded out, but what I want to do is kind of track a new path through it and just go right. There's more of these signals which make a hospitable well-architected, all that kind of code base where it all fits together, where we want to work, and we want to kind of wear code bases, right.

Doesn't even need to be how we put those bits together. That to me is super.

Marit van Dijk: And then we could have nice things.

Andrew Harmel-Law: This is what I can write. So we can write code that's so super powerful. Why do we write code? And I know.

Marit van Dijk: I don't think again, I don't think we also set out something we discussed in the previous session. I don't think we set out to write bad code. I think, you know, there might be constraints, time constraints, knowledge constraints, lack of sleep, whatever. Yeah. We don't set out to write bad code. And also the world changes and then we have, you know, code rots or, you know, there are newer versions of Java and dependencies might not.

Evolve as quickly or, might cease to exist. So, but I think if we have a place where everybody works well together, wants to do a good job and is safe to do so, we could have nice things.

Andrew Harmel-Law: I mean, it's not one person's job, right? So, you.

Marit van Dijk: Know, it's all our job. So is there anything that you want to say as a closing remark.

Andrew Harmel-Law: So by my book I'm being that finally so O'Reilly will boost me if I am if.

Marit van Dijk: I and I guess if they buy your book, the odds of your next book also exist, right?

Andrew Harmel-Law: So and if you want to find it more so. But I've also been advised, as I said, if you go to facilitating software architecture.com, that's going to be a free chapter, which teaches you how to set up your own tech writer. But it also has a link to the Martin Fowler blog, which is the shorter version. Right? It's got a full chapter breakdown.

It's got lots of extra supplementary stuff because it's long, but it turned out it was longer. And then Rita had to teach me the difference between important and essential. So all of the important stuff has been cut out of the book and is on extra stuff. There's templates like worked examples of change, sets of ideas also list. So.

Marit van Dijk: So we'll put some links in the show notes and people can start there.

Andrew Harmel-Law: And I'd love to hear oh and give me feedback. So that would be like this book is obviously all based on people telling me things. So yeah, that'd be really good.

Marit van Dijk: Awesome.

Andrew Harmel-Law: Thanks. Thanks, Marit.

Marit van Dijk: This is great.

Andrew Harmel-Law: Brilliant.