Andrew Harmel-Law - Power Structures and their Impact on Software

[00:00:06] So, I'll start the talk now. So, I'll start the talk now, so I don't run over.
[00:00:13] So, what I'm going to talk about today are power structures, so specifically societal power structures, and their impact on software. This bit isn't the talk. This is the bit where I'll explain the talk to you, because it's important you understand some stuff. So, uh, my name is Andrew Harmer Law. I'm a tech principal at ThoughtWorks. My pronouns are they/them, and it doesn't say it on the slide, but I'm also autistic and probably ADHD. That bit's important. So this is like, this talk means a lot to me. It's super important. So I'd love to have conversations about it. I'd love to have like Q&A about it as well at the end. But it also means that I might get carried away and go on side quests, which is totally an autistic thing. Which is cool, but if you're trying to make the talk last the right time, then it can be bad. So there is one side quest in this talk, which is intentional, and it has slides. So if I'm doing that side quest, that's fine. If I'm doing other side quests, you can like stare at me and like I will be snapped back to the room and I will remember that I'm supposed to stay on track. Um, but the thing is, how do you know that I'm on a side quest or I'm doing the real talk? You don't. So what you need to know is this thing here.
[00:01:33] So what is the structure of the talk? This is the structure of the talk. Part one, again, because autism, I learned a bunch of stuff, I read a load of things, and I'm very excited about them, and I'm going to tell you whether you like it or not. Many of them are depressing. So this is a warning. Because they're facts and I'm going to tell you, you'll like you'll, unless you can leave, everybody who's free to leave. But warning, the facts are going to be depressing. They start kind of fun, and then they get more depressing.
[00:02:02] That's the biggest part of the talk because autism, very excited.
[00:02:09] Then, because autism, I will realize I've shared too many depressing facts and that everyone is looking kind of sad. So now I will use my pattern matching and kind of pattern seeing abilities, again, God bless autism.
[00:02:24] I will try and understand and explain to everyone why we're so depressed, right? So I'll kind of give you like a mental framework of thinking about the reasons why these bad things are happening. But that won't make you feel any better, you'll just feel more understanding as to why you're depressed. So then that's part three. Finally, I'll tell you about some cool stuff which you can look at and look for.
[00:02:47] Um, to make the bad stuff stop happening. And then part four, which is tiny at the end.
[00:02:55] And it's secretly an advertisement for my book, because I wrote a book, which I keep forgetting to mention, I wrote a book. Part four, because this is all about freedom, or if you get it right, it's all about freedom.
[00:03:07] I will not tell you what to do, but I will tell you, I will give you a possibility to explore your own future so you can be free and do things. And the reason for all of this is write code which you are proud of and which everybody likes working with, because this is related to code.
[00:03:24] So that's the preamble. Now we can start the talk. So, like I said a minute ago, I'm going to talk about power structures and their impact on software. The reason why it's important is because software is a team sport. Very few of us get to write software on our own and we write the whole complete thing, right? Maybe you've got like a side project or that's how you start off like on your own. But almost all of us, I'm sure all of us are getting paid to write software with other people.
[00:03:55] And because of things that we've learned over the course of writing software, we all now kind of accept that outside external influences have an impact on our code. So, we definitely know that the structure of teams and the communication patterns between teams impacts our code, we call call it Conway's Law and we refer to like these things. And we know, even though like lots of it's anecdotal, I've seen it a lot, right? It definitely applies. We know it's true enough that we all laugh at the joke when they hear the joke, there's a um Michael Nygaard joke, which is the HR department. The human resources department does the first draft of your architecture because they decide where the teams go and that's what sets the architecture. And we all buy team topologies, right? And give Manuel Pace and uh Matthew Skelton some of our money.
[00:04:46] But I'm going to argue that it's social power structures too. Right? Because we don't just live in this world where it's just work. We live in the wider world where loads of stuff is happening, which I'm not going to talk about. But we all know loads of stuff is happening. This comes into the workplace and comes into the code that we write. So that's what this talk's going to do about it.
[00:05:08] But this talk, like I said, isn't going to take you for granted. What I'm going to do is try and describe and try and give you a bit of a picture of what happens and then try and explain why, or why I think it's happening, and then try and give you a reason to ways to get out of it.
[00:05:22] So part one, depressing facts. This fact is not depressing. This is a super cool keynote talk that Vlad Kononov did at DDD Europe in Check, I know it's 2022. Um, and it's called the fractal geometry of software design, because Vlad thinks very hard and he comes up with cool titles. It's a super, super interesting talk, and I will keep referring back to it. Because it's kind of Vlad's talking about the dynamics, the energy of software architecture and software design, and he's saying what we should do to have good design. What I'm going to do is pick it up and kind of say why I think it's impacted by societal power structures. What Vlad's saying is, is fundamentally the energy of software design and software architecture is around about the organization of knowledge. So, and you can see it in code, this is the easy bit, right, which is hopefully not controversial. He's like, there are different levels of organizing code knowledge, right? Basically, we're taking knowledge and we're encapsulating it. There's different levels of that encapsulation, so the levels of the encapsulation could be, I've got a list which I've just uncovered, because it was a domain design, uh, conference. The highest level was bounded context, because DDD people love bounded context, the next level down was services, the next level down was components, the next level down was modules. Inside modules are classes, so there's all these nested fractal elements, right, which we use to organize knowledge. So what they're doing is they're kind of putting a blind around the outside of knowledge, like they're bounding the knowledge. And then you have multiple of them.
[00:07:08] So this is software, right? But the key thing is, and this is what Vlad pointed out, which I think is super important, it's not just us figuring out where the knowledge goes. Because some of that knowledge is shared. And Vlad's point, which I think is super powerful. Is that managing that shared knowledge and being aware of it and how we take advantage of it is super key. And Vlad's other big point is the more we share knowledge, the more coupled our code is. So he says there's four levels. First level is the worst and it gets better. So, four levels of knowledge coupling. Number one, implementation coupling, it's the same code, cut and paste into two different places. So it's actually different, but it's literally the same, so if you have to make a change, you have to change two pieces of two places in the code, that's bad. Next level down is functional coupling, so it does the same thing but it's doing it differently. But you're changing the same thing.
[00:08:11] Then model coupling, and then contract coupling, so contract coupling is the least, right? So we're sharing a contract, but we're not sharing our internal representation. So this isn't new, right? This is what we learn when we learn software architecture and design. But Vlad's kind of insight is that it's all about knowledge and it's managing that. So therefore, if you have a lot of data passing over passing between two components or two bounded contexts or whatever, that are contract coupled, they're still less coupled than a tiny piece of data passing between two implementation coupled systems. Because the coupling isn't in how much data goes back and forth between the different components, the coupling is in like the knowledge which is at either end. So. That means the structure of code is the management of knowledge.
[00:09:02] And if we have good architecture, which I would argue good architecture means that we've got like a good a codebase which is more hospitable and is a happier place to be and to live in and to work is one which manages that knowledge and therefore it's one which manages that coupling. So, structure of code is the management of knowledge. structure of code is the management of knowledge.
[00:09:23] And that's the first fact which I don't think is controversial.
[00:09:27] Nobody's frowning too much yet, so this is fine. First fact, code is knowledge, right? So we take things we know about the world and we turn it into code. And the way that we share that knowledge affects the system design, right? So that's Conway's law and all of this stuff, right? So if if things are more coupled, then that affects the design and it affects the independence of teams. So the degree of sharing dictates the degree of coupling. But there's more facts.
[00:09:57] So, the inspiration for fact number two comes from this book by Adam Thornhill, which is your code as a crime scene.
[00:10:05] Which is a super good book. When I did this talk the first time, Adam was in the audience and I admitted that I hadn't read the book, which is bad. So I still haven't read the book, but I've worked with a lot of people who constantly tell me about the book. And the point of this of Adam's book is that code remembers. And so, obviously code remembers in the repo, in like our, you know, source control repositories, you can go back through Git and you can see the history of the source code. But more importantly, and this is why your code as a crime scene, you can see the traces of things that happened six months ago, one year ago, five years, like if. I work in a code base for a client at the moment, which is um, or I work near, not in, near a code base which is 20 years old. There are decisions that were made 20 years ago, which are still haunting the people who are looking after the code base now.
[00:10:55] And this is the point, right? Sometimes these things, it doesn't just record what, you know, it's not just what is known just now, it's a record of what was known in the past and how that knowledge was managed and how it was understood. So, fact number two, code is a record of knowledge, right?
[00:11:15] And it's a record of how we collectively understood a problem. Because we're probably not working on our own, we're working as a group, so it's the collective knowledge, right? And how we use code to manage and maintain that knowledge.
[00:11:33] And, like I said, because it's kind of still in the code base now, decisions we made in the past will have resulted in code which will be affecting the decisions that we make now, right? So if you want a good example, I'm sure you can maybe think of examples. The best examples are some of the design decisions which were made by the very smart designers and developers of the Java libraries, they made a few decisions, design decisions which haunt them or like the designers of the Java date util libraries, right? There's a load of stuff in dates, which they probably didn't think would be a problem, and now everybody hates them because everyone hates date, and then they brought in calendar, which everyone hates, and all of this stuff. So things that seem very small about how you maintain knowledge can result in big differences.
[00:12:18] So that's part, fact one and fact two.
[00:12:22] Fact number one, code is knowledge, fact number two, code is a record of knowledge. But there's another thing, which is important, and I think it's more and more important now. Like as as clouds and everything comes along and and and computers get more powerful. Um, we can do a lot of stuff with software, right? There's so much stuff we can do with software, we've kind of scared ourselves by building LLMs and using them and we're not really sure what they're doing and we think it's cool, but we're also a bit terrified, right? So software is pretty powerful. It's also burning tons of fossil fuels and slowly destroying the the ecosystem, but we're pretending that that doesn't exist because it's kind of cool that we can ask it to write code for us and it writes code for us. So computers are powerful. That power belongs to the people who have the ability to make a change in code and then push that change down to production, right? The people who have power to deploy it. And that power can be used for good reasons, for bad reasons, intentionally, unintentionally, right? There's just but it has power irrespective of how it how that happens.
[00:13:30] And so that power ultimately comes back to code. So code is super powerful.
[00:13:35] And it's conveying that power to people who can manipulate that code. So, minor side quest, that's what worries me more about LLMs than anything else. It's like lots of us are just kind of saying, like an LLM can write the code, that's fine, and then nobody's really in control, like some LLM is in control of it. So code is power. And so it's conveying that power to those who can manipulate it.
[00:14:01] So the best example of this is a blog post. And it's so small you can't read it on purpose, because I don't want you to read it, I'm going to summarize this blog post now. There's a blog post called the Rise of the Dungeon Master by Alberto Brandolini. He's famous for lots of reasons, including event storming. I think he should be famous for coming up with good titles for blog posts and good names for stuff, because he's good at it. But basically he describes this thing called the Dungeon Master. The Dungeon Master, or you could think of them as a game a gatekeeper, Dungeon Master to me is like a cool thing because I grew up in the 1980s doing role playing. And then somehow ended up working in computers, which I've no idea how that happened. But autism plus role playing equals computer science. Um, but yeah, so he describes this thing called the Dungeon Master. So the Dungeon Master is someone who has is like master, and I use the word master on purpose, probably not a mistress, because it's probably some white middle-aged person, right? Guy. They're master of the code base, right? They're master of the code base because they wrote it or they wrote most of it. And then all the other people left screaming. So they built this dungeon code base, they know where all the traps are, they know where all the mistakes are, they know where all of the like bad architectural decisions, all the things they're not proud of. They are the person, right?
[00:15:17] That means that if anyone wants to make some changes to the code base owned by the Dungeon Master, you need to go to the Dungeon Master because otherwise you'll fall in a trap and you'll get hurt. So Dungeon Master is the gatekeeper to all of these changes. That means they have a lot of power, right? They can say yes or no to stuff if they don't like someone. They can say no, even if it's a really good thing and even if the CEO says it's a good idea, we should definitely do this, if the Dungeon Master wants to say no, the Dungeon Master can say no. So there's a lot of power, they're all over the place. Everywhere I go, there's a Dungeon Master. Maybe you're a Dungeon Master, if you are, don't worry, I'm not being rude about you. Because Dungeon Masters, like if you read like all the old fantasy stuff, right, and you play all of these games, there's a there's always a backstory, they didn't choose to become like the Lord of this like stuck in this horrific dungeon or trapped by this code base, stuff just happened and they ended up being there, they're not doing it on purpose typically. I've yet to meet like an evil Dungeon Master in the real life. The best example in the Phoenix project is Brent. So when you encounter Brent, you're like, oh, Brent's going to be a jerk, Brent's going to be a bad guy, Brent is actually the hero person. He's like, I don't want to live in this dungeon where I've, I'm the person who has to be present for every single code change and I know about all of the weird shell scripts that I wrote to make everything stay alive. Brent is the Dungeon Master, but Brent is trying to fix the dungeon, clean it up, right, turn it into like a nice gentrified neighborhood. So that's the point, Dungeon Masters don't get there. In my experience, on purpose. So let's join some facts together. Code is knowledge and power, and they're kind of two flip sides of the same coin, right? So there's um, a phrase in English, there's probably a version in French, knowing English, we probably stole it from the French and then turned it into English. But the phrase is knowledge is power, there's probably a French version of this coming.
[00:17:13] Um, so they're the two flip sides, right? They're the inside and outside of the same thing.
[00:17:20] But the force, sorry, the third fact which kind of sits in the middle is the history. What's happening is is because because code remembers, it's remembering these kind of power dynamic and it's embedding and kind of ossifying and turning it into stone, right, making it hard to change because code is hard to change, right? We'd like it to be easy to change, Vlad would be very happy if you bought his book and discovered how to make your code easy to change, but the reason Vlad's book exists is because we're not doing it, and so Vlad has felt obliged to write this book.
[00:17:52] But it's not just like the power structures of like the teams and who people are, my argument is and I'm going to keep sharing some more facts. My argument is is that it's not just happening because of like organizational power structures, like who's the manager and which team is where.
[00:18:06] I think it's societal power structures too.
[00:18:09] It's not just a matter of who worked on which code and when. I think it's more powerful than that. So.
[00:18:16] I've lost my mouse, that's good.
[00:18:19] Because I think it's code is knowledge and societal power.
[00:18:24] So I'm now, as opposed to being someone who just stands on stage and tells you things because I think them, I'm going to provide more facts because I've read a lot of stuff on the internet. So number one. This um, paper is amazing, you should definitely read it, it's free on the internet. It's called Gender Differences and Bias in Open Source Pull Request Acceptance of Women versus Men. It doesn't pull any punches. You should definitely read it, it is really surprising. Well, actually, it's not surprising at all, but it's really surprising.
[00:18:54] Um, it's from 2016. What they did was they basically looked at all of the pull requests across all open source projects from GitHub, so their data set is big. Number one, like the data set must be small, no, the data set is big.
[00:19:08] So it starts off really interestingly, they hook you even from the abstract. As it says, surprisingly, our results show that women's contributions tend to be accepted more often than men's. And you're like, this is going to be an interesting read. amazing, you should definitely read it. It's free on the internet. It's called gender differences and bias in open source pull request acceptance of women versus men. It doesn't pull any punches. You should definitely read it. It is really surprising. Well, actually, it's not surprising at all, but it's really surprising. Um, it's from 2016, what they did was they basically looked at all of the pull requests across all open source projects on GitHub. So their data set is big. Number one, like the data must be small, know the data set is big. So it starts off really interestingly, they hook you even from the abstract. As it says, surprisingly, our results show that women's contributions tend to be accepted more often than men's. And you're like, this is going to be an interesting read.
[00:19:22] Unfortunately, however, women's acceptance rates are higher only when nobody knows that they're women, right? So women are writing the better code pull requests, but as soon as someone knows that they're a woman, then those pull requests are being accepted less. So they're accepted more when nobody knows who you are, soon as people like, oh, it's definitely a lady.
[00:19:42] Ooh. Right. This seems bad. If we just care about the code then this seems bad.
[00:19:52] So therefore, as they conclude, although women on GitHub may be more competent overall, bias against them exists nonetheless. So why? What could possibly be happening?
[00:20:02] In this completely meritocratic, egalitarian world of software, right? Where we all live?
[00:20:09] Because we're still experiencing bias, right? So despite the fact that these contributions contributions are better, because if we don't know the gender of the person then that's getting merged, right? They're less accepted, right? So it's also because it's open source. And this is what was interesting to me. You could argue, and I would like I think a solid case could be made if it was within an organization, if it wasn't open source, then maybe it's a secondary side effect of
[00:20:33] the fact that the organizational structure has come in and various people have been promoted because of, you know, how society and organizations work. There is no organizational hierarchy to protect in an open source project. You should just want the best contributions to your code base, right?
[00:20:53] So therefore, it's basically sexism, right? Which sucks but it's true.
[00:21:01] And so that's my my next point right, code is solidified knowledge and power, but it's it's solidified societal power, right? And because as we've got our facts, code is a written record of what has happened. Again and again and again, right? It's a written record of what has happened, but it's not a written record, just like in the historical record of what wasn't happened. It's not a record of the pull requests that weren't accepted. The codebase that you submit your code pull request to today, is a record of the is is on top of the pull requests that were accepted, right? So the code is remembering these things. The code is kind of offying, like turning into stone or bone, right, making it really hard. And it that's the current context in which the future pull requests are made, right? So it's not just the past, the past kind of catches up to the present. And then it's the world, the present in which we live, in which the future stuff happens, right? So it's the landscape of where we are just now.
[00:21:59] So this is sad, now we're definitely a bit depressed.
[00:22:03] Because like, I'm just even if you just are like slightly sad that there's good code contributions which are going to waste because of some stupid thing in society, even that's bad, right? Like there's a lot of other bad stuff. But just the fact that good contributions are going missing, that's bad. But maybe, maybe, thinking back to Vlad. Maybe this only happens on code bases where it's more structured, right? Because if there's more structure, you would think that the power may be in a code base, more structured. That power is even harder to change, right, maybe? So all we can do is,
[00:22:38] This is is basically a picture of a hole in the ground, but it doesn't look like a hole in the ground. It's very hard to find a picture of a hole in the ground which looks good. But if the code base is like a history of the layer of all of these changes one after the other. Where should we go to have a look at like the complete opposite? The way place we could go to look at the complete opposite is the Big Ball of Mud paper, right? Because the Big Ball of Mud paper is the classic description of the complete opposite, like if you want to make Vlad cry, you probably wave the Big Ball of Mud paper in his face and tell him, this is the reality of where we live. So look if you look at the Big Ball of Mud paper. What I forgot, because I reread the Big Ball of Mud paper, I forgot that it's structured like a pattern. It's not an anti-pattern, it's before we started describing anti-patterns in a different way. It's described as a pattern. So, if we want to build a big ball of mud, right?
[00:23:32] We start with a problem. This is why big balls of mud exist a lot because this problem is everyone's problem. We want to deliver quality software on time and under budget. Everybody, this is a direct quote from the paper.
[00:23:46] Nobody goes back to where they work and someone says that's not what we want. So we're all experiencing this problem. And so what we do is, we focus for a while on features and functionality, we ignore Vlad, we just ship the features. And we say we will focus on architecture and performance later.
[00:24:04] Right? Because that's obviously what happens. Unfortunately, later never comes.
[00:24:11] So that's cool, right, they describe the world all of us live in. They also, and this is what's interesting for me and for this talk, they focus on a bunch of forces which drive the big ball of mud, because these alone aren't going to make a big ball of mud happen. Why does the Big Ball of Mud happen? Number one, it turns out some people are good at working in big balls of mud. Which is a fact. Just all right. Like Brent in the Phoenix project is good at that because he can obviously write amazing bash shell scripts and can remember tons of stuff and is quite efficient at 3:00 in the morning when he's trying to fix a P1, right? That's just Brent.
[00:24:48] Number two, visibility of the structure. If I ask someone to build me a house, and I know architecture real world is a bad metaphor for software. But if I ask someone to build me a house and you start building, if Tron starts building me a house and it has all of the rooms I asked for and it has electricity and running water, but it looks like it's going to fall down next week, I will be upset because I can see it.
[00:25:13] You can't see that in code, right? Even if people are like, it's really bad, but like product managers and all, you know, the CEO can be like, I know, but it's fine, we'll ship, we'll do it later, we'll just ship it. The only people that can see it, architects kind of get a smell of it, right, if you're working as an architect, which is what I do. But the people who really know are the people who are in there getting all of the paper cuts every single day, right?
[00:25:38] Number three.
[00:25:41] I changed the word complexity because it triggers some people because it's not technically complexity. It's the complicatedness of making changes. In other words, it's flipping hard to change the code, right?
[00:25:52] And this is how it slowly drifts if you're starting off with something which is really nice and makes Vlad happy, right? So it's like shared um coupling via our interfaces and contracts. If you want to move fast, designing a contract between two teams is a lot slower than just going, I'll just cut and paste the code from their code base and I'll put it in my code base and we'll fix it later. So everything drifts back up that list of things and makes Vlad very unhappy. But that makes it go faster. So the system erodes. So therefore, it's hard, so you need someone who's more skilled at working in the big ball of mud. So the negative flywheel gets going.
[00:26:27] Next boring, depressing quote, many engineers regard working with a Big Ball of Mud as normal. This is like I've never been anywhere and I'm lucky enough to be a consultant. Everywhere, everywhere has a big ball of mud somewhere. Maybe it's their whole system, maybe it's half their system. Everyone just assumes this is naturally where it's supposed to be.
[00:26:50] And some engineers are particularly skilled at navigating those quagmires. So this is the extend the metaphor.
[00:26:58] And as a consequence, the people who really care about stuff, the skills of someone going, we should design this properly, we should do some refactoring, we should update the architecture. They can ask for it over and over again, but the thing they're asking for is getting bigger and bigger. But the forces are to make it just work, just deliver the feature. We'll come back next week and we'll fix the thing, the architecture, right? So swamp guides become more valuable because they can just ship, right? Brent got to being Brent in the Phoenix project because Brent could ship. Even though Brent, you know, like Brent knew that it was probably a bad thing, but it's more important that the company makes money, right? So the swamp guide slowly become gatekeepers, right?
[00:27:38] So code is structured knowledge and power.
[00:27:42] But this is a key point, not everyone is becoming a swamp guide, not everyone is becoming Brent, right?
[00:27:48] There is a good question, why is Brent or the gatekeeper or the dungeon master always a middle-aged white guy? And it's not that middle-aged white people, male white people, are bad, right? Nobody's doing this like thing. Like if this pattern was happening over and over again, that would be a bad thing, right, so something else must be happening.
[00:28:11] And my argument is, and I'm going to try and explain why in a second, all of this stuff is happening over and over again because of societal power structures, right? There is stuff that's impacting and affecting and pushing us in a way that this is happening over and over again.
[00:28:25] So, last set of depressing facts.
[00:28:29] This is a paper which has nothing to do with software. It's called The Tyranny of Structurlessness and it's a paper about the experiences of second wave feminism written by Joe Freeman. Um, I think in the 70s or 80s. But basically, Joe was working in groups of like structuralist groups, self-organizing groups. But which explicitly had no structure. The whole point was, screw patriarchy, we're going to have no structure, we're going to just organize. It worked totally well for consciousness raising, so when people were explaining things and teaching each other, it was amazing. Joe's paper, however, points out that as soon as those groups start to move towards going to do things, like even making flyers, right, to change society, things started going wrong. So,
[00:29:21] And Joe's point is, structurelessness doesn't exist, as soon as you try and do something like write code, right, there is a structure.
[00:29:30] So,
[00:29:32] the idea of structurelessness does not prevent the formation of informal structures, right? All it stops happening is if you go, oh, we can't have any structure, it just stops formal structures. So again, if Romeo says, we should definitely have a regular meeting and we're like, no, that's a structure, we can't have a regular meeting. They might still be frequent meetings, but like it's just like they're informal, right?
[00:29:57] Structurelessness then becomes a smokescreen for the strong or lucky to establish unquestioned hegemony over others. Hegemony is a hard word to pronounce, so I've practiced it. So this sounds evil, right, so it sounds a little bit like I've fallen off a cliff on the internet. And I've gone down a rabbit hole and I'm getting all paranoid. It gets worse.
[00:30:17] Because then Joe Freeman uses the word elite. Now elite is a supercharged word, right? These days, the elites.
[00:30:25] I don't mean those kinds of elites. Joe is like, the elites are the people who do this. But how does Joe define elites?
[00:30:32] An elite, boringly, is a small group of people who have power over a large group which of which they're a part. So that sounds kind of suspicious and scary, right?
[00:30:42] Luckily for us, elites are nothing more, nothing less than groups of friends, right? So Joe's not gone paranoid. It's just people who hang out together, right?
[00:30:54] And what's happening is these friendship groups, because they're like each other, right, function as networks of communication outside of regular channels. So if we think of like Conway, the communication patterns are dictating our software, right? So sometimes if we're like, there are no communication, there are no formal structures which is how if you've got teams, the teams are communicating, it's obvious. Because Conway talks about communication patterns, not teams, right? But it works because typically there are formal teams. The stuff still works, communication patterns still have an impact on things, software, because software remembers, even if there is no formal structure.
[00:31:30] Because there is a structure, it's just informal.
[00:31:34] So,
[00:31:36] elites sound cool, how do I want to be an elite?
[00:31:40] Luckily for me, to be an elite, you don't need. the right or sorry, you do need the right background, white skin, male. The right personality and the right allocation of time. I don't have any spare time. But if I had lots of spare time, I would be the right person for this. Also luckily for me, membership of elite does not include requirement for me to be competent, which is good, because I'm not competent. Dedicated to feminism. I'm quite dedicated to feminism actually. But in this case, dedication to the shipping of good code, that's fine, I don't need to worry about that.
[00:32:12] I don't need to be talented. Or I don't really need to potentially contribute. So this is good. I can like run around Europe doing talks and still be a member of an elite.
[00:32:27] And so this is the key thing, so code, and this is the point I'm going to this is the last bit of the depressing stuff, then we'll get to the slightly less depressing.
[00:32:34] Code is structured knowledge and power and it's structuring things whether we like it or not, right? It's embedding, it's remembering things, the things which the societal power structures, as we've seen in the in the GitHub paper, are kind of allowing and it's not remembering things which we don't get a chance to remember, right?
[00:32:54] It's putting that down into the code and it's remembering for a very long time.
[00:33:00] It's capturing all the groupings and all of the biases which we have not because we're bad or good or because people are choosing to do things, it's just all of the unconscious stuff which is happening in society is just happening because code is is like super good at remembering this stuff, right? It's amazing how it manages to do it. So all the human frailties which we all live with, right, and lots of us are trying to like fix. But like if you do nothing, it'll just kind of bleed into the code base anyway, right?
[00:33:29] You don't need to be bad, so to be very clear, I didn't say this when I gave this talk last time. And I think upset some people, you don't need to be a bad guy for this to happen. You're not a bad guy, and it's probably, it will be a guy, you're not a bad guy if you're an elite, you're just
[00:33:41] you're by an accident of birth, you're predisposed to be in this thing, right, where you have more spare time and etcetera.
[00:33:50] But this is happening to code, right? So.
[00:33:56] That is the eye of Sauron, for some people who are already forgetting it out. So,
[00:34:03] if this is happening, right, and I would argue, so this is happening and it's predisposing things to be big balls of mud, which is making Vlad sad. So if the one goal you have from this talk is to make Vlad Konlov happy. He's a lovely human being, he deserves to be made happy. He's buy but you can buy my book. I've got free copies. Um, but like buy Vlad's book as well. But how do we make Vlad happy because Vlad's point is making if we have structured knowledge management then that's a better code base to work in, right? It's less coupled, coupling is literally the bane of everyone's life. If we have more managed, cognitive load is easier, changes are easier, it just gets better fun to do our jobs. So that's the argument, right, not because we should all like do everything else.
[00:34:46] So.
[00:34:50] If we're in this system, how do we fix it?
[00:34:54] What might we do to change it? Can we work with this whole knowledge as code as knowledge and power thing? How can we make it work for everybody, so like still make it work for me, but like make it work for everybody else, right? To do that, we need to know how the imbalances are right. So it's a fashionable book to quote, you should definitely read it. There's a load of criticisms. I'm not an anthropologist or an archaeologist, so I don't know if it's correct or not. The reason I'm mentioning this book, which is the um Dawn of Everything by David Wenrow and David Graber,
[00:35:29] is in the book they make an argument that there are different ways of organizing, right?
[00:35:34] There are different ways of organizing which don't have to be the way that we currently in the West organize our societies. It's just that everywhere we look, that's how society is organized. But they've got tons and tons of examples of different ways, different societies organized for thousands of years. They even talk about some societies that organize differently depending on the time of year, so they'd flip their like organizational mode based on the environment. Which is cool. So.
[00:36:01] Why is this important? Ursula K. Le Guin quote, We live in capitalism, its power seems inescapable, so did the divine right of kings. It feels like, you know, sometimes it feels like this is just how it works because it works, right? It's not working equally for everybody, it's working better for some people than other people. But if we get a, you know, like a code base, if we just restrict it to code bases which is easier for everyone to contribute, then I can benefit from all of the smart intelligence of all of my colleagues. And we can have get good stuff. So, as Ursula reminds us, human power can be resisted. So it's just we made it up. We can make up new stuff. So, what do we make up?
[00:36:40] There are three prerequisites for power to be unequally distributed, which is how these things come about. Let's look at them. The first one, this is the side quest I'm allowed to go on. Is this one. Writing code is cool. Let's be like super honest. There are very few careers where if you stopped paying us, we would probably still write code. Right? We wouldn't write it for the company that aren't paying us, but we would probably still be doing something, we would write code because writing code is cool, right? It feels amazing. Unfortunately, we very rarely get to write code on our own, right? So what we have to do is we write code with other people. So when we write code with other people, some of those freedoms that we have when we're on our own have to be given up because I don't want to upset or get in the way of everyone else who are doing their job. So we need to give up some of these freedoms, right, it's not bad, it's just how it works when society organizes. So, I've got loads of these little things. We need to give up some of that power, the ultimate power that we have as individuals to like to work as a team.
[00:37:47] So. I've got too many of these. So. There are important things that happen when freedom removal happens. And this is what you need to pay attention to. And this kind of goes to almost some of the points that Steven was making, it goes to some of the points that Thierre was making yesterday. You need to pay attention to certain things, right? Because removing a freedom is important. Who decides which freedoms are removed? So you'll hear like Stephen earlier in the talk just before me was talking about like he doesn't go and tell the teams this, he goes and asks the team if they should do something. Terry again was talking about autonomous self-managing teams, right? So who is deciding?
[00:38:25] Who is enforcing it? Right, if you say, we need, I think it's a bad idea, but if you say two people need to comment on a pull request and only one person pull, you know, or nobody comments on your pull request and then you just force merge it. Someone's got to say that's not cool, right, so who does it?
[00:38:42] And who updates it, right? So sometimes the rules change. Again, Steven was talking about the fact that when they started small, you don't want to like, when there's a small group, you have a few freedoms that are removed. Because you don't need lots of bureaucracy. Because I can shout over the like the the the cube to the person next door to me and they'll fix it. But if it's bigger, then maybe we need a slack bot. If it's bigger, at some point we'll need Jira, probably, right?
[00:39:08] So, this is where we get super French. So if you've like, you can pay attention, if you don't know who it is, you can read the bit down the bottom. Because I did this to talk in another country and I realized nobody should be expected to know about French history. So, number one. Freedom to pay attention to number one is like who curtails the freedoms.
[00:39:27] And in the book, it's not control of punishment, but I don't want to go too hard in this talk, so I've changed it to control of punishment. If you want to read the book, there's a stronger word than punishment that they talk about. Key thing is, you need to pay attention to who's controlling punishment, right? If it's one fabulous looking white king dude, then things might go wrong, you can see where this is going. but we'll need Jira probably. Right?
[00:39:07] So, this is where we get super French. So if you've like, you can pay attention. If you don't know who it is, you can read the bit down the bottom. Because I did this at talking in another country and I realized nobody should be expected to know about French history. So, number one, freedom to pay attention to number one is like who curtails the freedoms? And in the book, it's not control of punishment, but I don't want to go too hard in this talk, so I've changed it to control of punishment. If you want to read the book, there's a stronger word than punishment that they talk about. But key thing is you need to pay attention to who is controlling punishment, right? If it's one fabulous looking white king dude, then things might go wrong. You can see where this is going.
[00:39:48] The key thing is is in the world of software, there are formal punishments, which are like, who gets hired, who gets fired, who gets a pay rise, etc. That's all, you know, and we all know about this stuff, right? Things can happen. Five minutes. Oh, I might go slightly over. Um, but in code as well, the informal stuff, like who gets asked to do the code reviews, right? Who's, you know, code is like trusted more etc, etc. The informal stuff in code, I think is as if not more important, or like more kind of restrictive because of the power of code, right?
[00:40:24] Key reminder number one.
[00:40:27] Again, you don't need to guess what it is, it's the tennis court oath. But like, you can't remove every, if you remove all control, it'll be chaos. So you need to have some form, we all know, most of us probably know. It didn't go well, but it started out okay, right? So what you want to do is keep it going, okay? You do need to give up some freedoms. You can't just give up like have everybody having all freedoms because you're trying to collaborate as a group, a small society trying to ship code, right? And maintain code.
[00:40:55] What you need to watch out for is when certain key people have all of the power to do those key three things, right? Like deciding who decides, enforcing things and changing things.
[00:41:08] However, some people just don't care, right? They act like, okay, I know I could get fired if this thing happens, but I'm going to do it anyway, right? So there must be another source of power, which those people have, which doesn't relate to whether or not they're at the top and they can dictate what's going to happen, right? Why are they acting without fear? So that's the second thing that Graber and Wengro point out. And it makes sense if you think about it, working with code gives us power, right? Brent becomes important in the Phoenix project, but they're kind of pulled out from like the lower levels because of the person with all of this power. So what power is it that they have? They've control over information, or they understand the code. Right? Understanding the code is super powerful, right?
[00:41:56] So therefore, we have access to that power. If the code isn't nicely managed, right, if it's not making Vlad happy, and certain people know everything about certain parts of the code base and no one else does, that's bad, right? We all know it's bad, but this is the reason why it's bad.
[00:42:11] These are the people who become the big bowl of mud swamp guys, they're the people who are kind of naturally predisposed to be the elite, they're the people who can work light, right? I might be really good at working in big bowl of mud code bases, but if I have to go home to my kids, then I can't. Someone else might be equally good as me, but then they don't have kids and they can work till midnight. They're just naturally just because of how life is, they're more predisposed.
[00:42:34] So my point is this code supercharges this. This one you might not be aware of. This is Edmund Burke, an Englishman trying to terrify the English about what's happening in France because in England they used the terrible events in Paris as reasons for like extra repression in the UK because we're like, well, we don't want that to happen because look what's happening in France. So, code supercharges it in the same way, right? Like you can kind of have this extra power. So,
[00:43:03] It's so powerful, we do it accidentally all the time. I can write code before lunch that after lunch I don't understand. So code has this power, right, just by giving something a bad name, that it doesn't work. Or you think about like code, like I can write code, and then leave a client seven years later, that bad code can still be having a power over people because I didn't put the right stuff in. Two minutes. I'm going to go fast. So given this, why don't we see power imbalances everywhere? Well, to do that, we need to remember the things. You need control of punishment and control of information. But there's the third factor. What's the third factor? What Wengro and Graber point out is, you don't need all of these three things. I'll tell you what the third thing is in a minute. You just need two of the three. So typically, you see someone who's high ranking who knows all of the bits about the code, right? But what happens if you've got someone who just knows about the code and who isn't high ranking? What have they got?
[00:44:00] Individual charisma. So guess who we're going to see for that? It's Napoleon Bonaparte. So, a small, really small person from Corsica, suddenly like comes along and some would argue because of really big charisma, like everybody like followed what Napoleon was doing. And you can see this in code, right? Like sometimes this code, and I've got another picture here, this is a collection of Linus rants.
[00:44:28] There are parts of the code base that are hard to change because they're hard to change in everybody's code base. There are parts of the code base, which I've seen over and over again, which are hard to change because you're scared of upsetting the person who wrote the code. Right? And they're probably not a high hierarchy person. I know in this case Linus is is top of the tree. But you see it as well, like people are just like, it's terrifying because of the charisma which with which they have.
[00:44:54] And they're both really hard to dislodge. And because of code, like power can disappear, is going on. Power can disappear if it's not kept somewhere. Informational power, right? Suddenly if you're not know, but the problem with code is, code is really good at being difficult to like, it's very hard to dislodge people who get sucked into this thing. And again, nobody's doing it on purpose. People are just being sucked into it because they've got more spare time.
[00:45:21] So, unequal distributions of power are a problem.
[00:45:25] So what do we do to fix it? So to be to fix it, we need to be aware of the forces operating, and to be aware of the forces operating, you need to listen to what's happening, right?
[00:45:38] And you'll fall into the same trap. If you like are high up in the hierarchy and you're like, I'm listening, it's very easy to think you're listening to everybody, but you're not because you're high up in the hierarchy and there's a bunch of people who aren't in the same meetings as you, saying stuff, but you aren't aware of what they're saying. So to do that, you need to do a bunch of things. You don't need to just involve everyone, because that assumes that even if they're involved, they're going to want to participate.
[00:46:03] So you've got to look out for like informal groupings appearing, which aren't bad, right? A bunch of people going off to play football, sorry, play football on a Friday is not bad. But you're just like, okay, are those people also becoming the people the team which always fixes stuff, right? So we need to make sure that's not happening. We need to look out for people hoarding information. I'm look out for people hoarding information.
[00:46:25] Specifically there's three freedoms we can look out for.
[00:46:28] So number one, we need to protect the freedom to reorganize. So freedom to reorganize in software is important, right? So it counters the control of punishment. If we can reorganize, if I can refactor a code base, right? Then that's a good thing. It means I can freedom to add, remove or change the boundaries, right? If I think my team should like should own more stuff, I should be able to speak to the team that I think I should take something from and then we can self-organize between ourselves, right? I shouldn't have to go to management to say, should this come to us, right? It should be allow us to like move from team topogies design one to team topogies design two in our organization.
[00:47:07] But the need should come from the collective, right? Everyone should be free to reorganize. Not in chaos, right? Again, remember we have to give up some freedoms, but there should be a mechanism for saying, I think the boundaries or the code needs to be refactored and it should come from anywhere. Number one. Number two, freedom to move.
[00:47:24] Freedom to move counters the freedom control of information. So this isn't just the freedom to leave, this is the freedom to be to either move to different parts of the code base, to move to different teams. Or the freedom to move someone from a part of the code base, right? No one person should be stuck on a piece of the code base and be like, you can't move me, I'm the only person who knows about it. So all these things we kind of know, but this is a really nice way of thinking about it, right? So no one should be irremovable.
[00:47:53] And then three, freedom to disobey. So again, with the caveat that, this doesn't mean you can be a jerk. But you should be able to, if there's like, this is a thing we will all generally do. But if you've got like a nice, well-architected code base, like Vlad talks about, the reason you have as minimal sharing information as possible is because if I want to do something in my team which is different from another team, but my changes will have no impact because we've got lovely encapsulation, right? And we have we're not going to cause a change on any other team, then I should be able to do that, right? I should be able to disobey and change locally, institute a different way of working as long as we keep the overall goal, which we're all aiming for in mind to go together. So, make Vlad happy. Is what the subtitles for this talk could be. So, surrender the necessary freedoms to collaborate because don't be a jerk, everybody hates jerks. But surrender the freedoms, but make sure you're surrendering the right freedoms. And those freedoms are freedom to reorganize, freedom to move and freedom to disobey. Because the point being if we, and this is the conclusion, if we all pay attention to them and we collectively look after these freedoms, what we're doing is we're inoculating ourselves to the slow gradual drift towards big balls of mud. That's the point, right? I'm not saying you should all be like dedicated like the, you know, peak feminist and and all of this kind of stuff, right? Or anti-capitalist or whatever. But what you want to do is be aware of these things so you can see the forces operating, so you can protect against the big ball of mud and like have a conscious architecture, right?
[00:49:30] Because if it's good for everyone, then by definition, it's good for you, right?
[00:49:37] And then, if we have code bases which we can actually control and we actually like working in, then heaven forbid we might like enjoy our jobs even more. So that's the kind of thing. So do this for like the benefit of the code base, for the benefit of you, that will benefit everybody. So that's it. So finally, last bit, choose your own adventure. I wrote a book.
[00:49:58] It's 520 pages, but if you want the one page summary, this is what you do. So it's all based on this. Basically, one way to supercharge this is to adopt what's called the architectural advice process, and you can say, you say this basically, anyone can make any decision, and that means any decision. But before doing so, and this is the kind of counterbalance, you need to seek advice, not permission, advice from all the affected parties. So someone, basically someone who would have a story put on their backlog because you did something.
[00:50:29] So if you're going to affect them, you tell them, and people with expertise, and that's it. There's another 519 pages of my book which explains how to manage all of this stuff that happens when like you get humans talking to each other, but that's fundamentally what it's it. So thank you very much. I think we still have time for questions. <noise>
[00:50:58] Oh, and there's books. I think you got there's books. You get a copy of my book if you ask a question. Question. Yeah. Question.
[00:51:07] All right, thank you. <noise> So apologies if you already bought my book, but thank you if you already bought my book.
[00:51:17] How did you came up with all those reflections? How that was born in your brain?
[00:51:22] That's a good question. I think I read too many books.
[00:51:27] So, I read too many books, but because I'm I'm lucky because I'm a consultant. I get to see tons of stuff, and I could see the same people being frustrated about stuff. I see big balls of mud everywhere. You could like just loads of stuff. People were frustrated, but the thing that annoyed me the most, people were accepting the fact that this is how it is. And then I started experimenting with the decidedly anarchistic advice process.
[00:51:56] Cuz I was like, if it was easy to solve, then somebody would have tried it. So I tried it with a few clients and it actually worked. And I was like, wow, this is like, this is there are different ways of organizing. Not necessarily at societal level, I know it's very different, right? But this kind of organizing in teams works amazingly well. If you trust people and give them the power to try and do things differently, it's amazing what happens. And that was it. So I was like, okay. So then I was like, oh, then I wrote a blog post for Martin. Actually, I wrote a Twitter thread, now I would write a blue sky thread. moaning about it. Then I wrote a blog post for Martin Fowler and then I wrote a book because every time I wrote something a bit bigger, people tried it and told me it worked. So I don't think it'll work for everyone, but I think you should give it a try because you'll be surprised if you trust your colleagues, it's amazing what happens. So,
[00:52:53] There you go. There's two copies left.
[00:52:55] Um, thank you for your talk. Thank you. Um, whenever you give a space of freedom to someone, it doesn't mean they will use it. Yeah, yeah, yeah. Uh, what's the first step for helping them, um, having room to occupy that freedom space?
[00:53:15] So room is the right word.
[00:53:18] So you're right. If you make space, if I'm like, so typically, I am the person because of who I was born as, I am the person who has the power and I can give it away. It's very hard to take the power if you don't have it, right? But so this works best if someone like me says, okay, I'll step back. So you make the space for people, but you're exactly right. Just because you make space is no guarantee that people will be like, this is amazing, we'll just do all of this stuff. Typically there's just a big pause, because people don't believe that you're stupid enough to do it, because who would trust people. And they're unsure because previously you or someone else has done all the work, done the software architecture, done the, you know, the organization of the teams, etc. So they don't have the experience, so they're scared. So what I then do is, I'll try and model the process, just like parenting, right? Where you'll like try and model the right behavior and do it transparently and in the open and try and encourage people to take up the power. Not everyone will, not everyone should, right? Not everybody wants to be like a leader doing stuff. But making sure the space is always there, and for me, this is a bit in the book, I'm autistic, so I talk quite a lot, learning to shut up is very powerful. Which I'm not good at. But like making space and then holding the space, and like encouraging people into it, or if you move into the space and then do stuff, being aware that you're taking up space and then kind of retreating out of it afterwards is, is key. So then there's a, so not to talk about another conference, but next week at QCon London, the first company that I tried this with in 2020, they're doing a four-year retrospective and they're going to talk explicitly about what it felt like. So they might be, I don't know if they're going to be rude about me. And this will be the last question. Yeah.
[00:55:09] Um, thank you for the talk. You talked about it quickly, but regarding LLMs, uh, now we have people that can code that couldn't before, uh, like vape coding, etcetera. Uh, for you, is it some freedom gains for people that cannot code because code is power. Yeah, yeah, yeah. Or is it uh, freedom removal because LLMs are owned by uh, big tech companies, uh, and tech fascism, etcetera. Yeah, yeah. Um, what do you, what are your thoughts about it?
[00:55:45] So I think it's both. I think it totally does empower things, and there's a really cool talk I saw, I can't remember what it's called, but um, something about like local coding. So it is democratizing coding, which is a good thing, right? It shouldn't be like this only a certain type of person should code, right? Everybody should be able to code. Um, to a greater or lesser extent, right? Some people make full careers out of it, some people just need to do a little bit. That's important. What worries me is, just like you said, it's very easy to generate a lot of code, and that code is knowledge, and that's coming from an LLM, which is just got tons of assumptions. Which, like if we go back, right, so Tim Gebru, oh, it's not going back. Ah. Oh, maybe it's going back. Down the bottom, they were the Google data scientist who who is like, if you're a straight white person, LLMs are perfect and they're reflecting your reality. If you're not, LLMs are not reflecting reality. So you can change them and fix them, but you need to be aware. What worries me is like everyone's just assuming this is reality, and it's not, it's a very specific viewpoint. It's not an invalid viewpoint, but there are many other viewpoints. It worries me that people are just assuming that this is the one true viewpoint, and then yeah, power goes to that one place, and that's being aware of that is super important. But I mean, just like it's easy, right? We know that like half the rainforest burns down every time we run a query for an LLM, but we don't see it, so it's kind of okay. One minute, we're done. Oh, we're not done. Last question. We are done. Okay, cool. Sorry, everyone. I need to leave, right? Thank you very much. Thank you very much.

Transcript