 How's the sound? Good? Okay. It feels a little weird to have the microphone like right there. But I'm going to go with it. Good morning. Okay. Thank you. It took a minute. Let's let the coffee sit in for a minute. I'm very pleased to be here. This is my third Rocky Mountain Ruby. And my first one in Denver. Is this the first one that's been in Denver? Second one in Denver. My first one in Denver. I do have a soft spot for Denver actually though because it was here that I did my first ever keynote at RubyConf in 2012. And that was the talk that sort of kicked the speaking part of my career into high gear. And for the past few years as Jeff mentioned I've helped run RubyConf but this was way before that. And I had just submitted a talk through the CFP through the normal channels and they were like hey you should come be a plenary session. I had to look up what that meant. It's like oh oh a keynote. So the other two keynoters at this conference were you know no big deal. It was just like Matt's the creator of the Ruby programming language and Jim Wyrick which is who's an old school American Rubyist. If you've ever typed rake or gem install you have used some of his work. So I was pretty intimidated to be included in that set. But I did a talk that was in some ways kind of a precursor to this one. But I gave it a much more pretentious name. I called it the insufficiency of good design. And if you ever want a reason to cringe I highly recommend watching a conference talk that you did five years ago. Which is sort of like looking at code you wrote five years ago. And you're like really I thought that was a good idea. But this was the first talk I did that really explored the relationship between teams and the code bases that they produce. And that's been a big part of my thinking in software since then. So I'm excited to come back to Denver and give you the five years later hot take. Hopefully slightly better thought out than the one from 2012. So livable code the theme of this conference is trust. And when I heard that I initially thought I might need to write a new talk because this talk is not about trust. It's talk about code. Which of course then means it's a talk about teams. Which of course then means it's a talk about trust. And there's a lot of people here I haven't met before. Let me tell you a bit about my background. Jeff basically covered it. I'm based in San Francisco. I'm currently as chief architect of mine software. And I've been doing consulting now for about 10 years which makes that almost half my career. I've been a developer. I've been a manager. I've been a team lead. I've been the expert. I've been the noob. I do a lot of community work as he mentioned. RubyConf is in New Orleans this year. So come on down in November. We just released our program. Jeff mentioned Railsbridge. Railsbridge was probably the biggest turning point in my career though as far as community work goes. And that happened in 2009. Another developer Sarah Allen and I founded Railsbridge and we were one of the first organizations to give women and other gender minority folks a free place to learn programming if they were new to it or to learn a new framework if they're coming back into the job market after some time away. And at that time in 2009 there were no code schools. There was no place to send people if they wanted to learn more other than to like meetups and conferences and books and the internet right. And to be honest at the time when we were planning the first one we weren't really sure any women would even be interested in learning Rails. But we posted the first workshop through the San Francisco Ruby Meetup account and we thought well even if nobody shows up our sponsors buy us lunch so we can just sit around and talk to each other and have lunch. But then less than 24 hours after we posted it it was completely full and had a waiting list of 125 people for 30 slots. And so there's definitely demand and the workshops we did over the years they helped generate that demand for code schools. They demonstrated that there's an underserved market out there of folks who didn't come to computer science or to programming during college like I did but who definitely had the mind for it. And doing these workshops and meeting folks who took to it immediately despite in some cases having never written code before fed my internal sense that something was wrong with the way that we thought about tech. That somehow we were using the wrong model that the way that I had been trained in my computer science degree to think about software as engineering or architecture or construction or manufacturing that all that really was insufficient right. There's so many things that a mechanistic math oriented model didn't explain. So for example if what we're doing is like creating a physical product then why is software never done anymore. If we're if we're engineering solutions why can't we ever really plan ahead. And if computer science fundamentals are really that important why are interviews the only time I ever need to think about runtime complexity. And I kind of felt this vague sense of wrong ever since my computer science classes in college but it's taken me a long time to articulate it and even longer to come up with an alternative model. And this that talk here in 2012 was my first try at that. For the last few years though as I kept on writing code and pairing with clients and doing all that stuff. I've also been working on two new models for software one for development teams and one for code bases. And what I'm trying to do is capture software as it is when it's done well and like any good model help us understand what to do in novel situations. Now we need two models because software is composed of two related interconnected but distinct entities and that's the team and the code base. One of the most influential ideas on my thinking about software is something called Conway's law. Conway's law was formulated in 1967 which at this point by the way makes a 50 year old idea. And it says that the structure of your code will recapitulate your team's communication structure. Now that sounds pretty abstract but let me give you an example from an early startup client I had. They had a team of five engineers. And number one was sort of the manager he was in charge and tended to broadcast information out to the rest of the team. But it's a small team structure was functionally flat as a startup. So their internal lines of communication were quite good as well. Their architecture for their system was five different services written in five different languages. Number one was the orchestrator. But the others talked amongst themselves as well. So in this case their code literally reproduced their org chart. Now when you have a team who's all working in the same code base this could be harder to see but it's still there. And the reason this is so useful is because it means if you see a problem in the code it's reflecting a problem in your communication structure. Messiness in the code reflects messiness in the team and your interconnections as people or even in how your teams relate to each other. And what that means is that for any problem you have writing software you have two directions to approach it. You can make changes to your team which drive changes in your code base or you can make changes in your code base which then drive changes to your team. And for any given issue you can do one or both depending on which seems more effective. Some problems look like they're purely code based. Some problems look like they're purely team based. But all of your problems are both. Right. For example if your code base contains three competing implementations of user login you could consider that purely a code problem right. It's technical debt that you need to pay down at some point. But it also represents a communication deficit amongst the members of your team because presumably if they were in better communication they wouldn't have implemented three independent implementations of user login. And if you fix one without fixing the other you're likely to see it return. And so that's why we need two models because the team and the code base are equally important but distinct parts of a software system. And this talk focuses on the code base side of the equation. I've talked about Conway's law. I want to mention now the other idea that underpins my thinking on software. And that is a paper from computer scientists and software engineer Fred Brooks. Written in 1986 called No Silver Bullet Essence and Accident in Software Engineering. Now Fred Brooks is better known for a book called The Mythical Man Month. But I actually find this paper more relevant. More compelling for me. I read it about once a year. So the paper says in essence that it is not possible to create a tool or process that makes software engineering orders of magnitude better. That there is some irreducible complexity in software that doesn't exist in other parts of engineering like civil engineering or hardware engineering. Now when Brooks wrote his paper in the 80s right hardware chip speeds were doubling every 18 months and people were sure that there was a software equivalent out there somewhere. But Brooks said no. There's something different about software from every other sort of engineering. I don't know what it is but it's different. Doesn't conform to the same rules and therefore there really isn't a way to make big leaps forward. And our primary metaphor for a software team is often something around something along the lines of manufacturing. We are making a product. See there are like sort of an assembly line where workers assemble a product or it's a workshop where you handcraft each one individually. But in either case we usually think about it as a product. That doesn't quite fit the way that we write software in the modern day. Right. It's not much like a physical product that we're manufacturing. It's more like an experience that incorporates the development team but also our code other people in our organization even our customers. It really is at its best a group creative effort. And it's more like a group of theater people putting together a play than a group of workers fabricating something physical. And the reason this matters is that teams are more successful when we think about them as groups of creative people collaborating. And this model gives us more information and predicts more behavior than a manufacturing model does. Even though many of us who work in tech particularly programmers are not really accustomed to thinking of what we do is creative. So we need to make a similar shift in the way that we think about code. Right. One thing Conway's law tells us is that if there is a rule that applies to the code base there's another rule that applies to the team. So what's the code base version. So for me the difficulty in code has always come down to this word architecture which is somewhat ironic because I'm the chief architect. So for 50 years we've been told that what we do is like architecture or maybe earlier in our careers is more like construction right. We're taking someone else's designs and we're building them. But our goal at least on the individual contributor non manager path is to be the person that makes the plans the architect the person who ends them off to other people presumably earlier in their career is to do the actual building. But there's a problem in our thinking about software this way is building something and that's that it doesn't really reflect how it works anymore. Creating a building has three very defined phases there's planning phase the construction phase and the maintenance phase. And software projects used to look a lot like that right. Software projects used to be done you'd finish it you'd press it onto CDs you'd mail it to your customers. And then the developers would hand the project after someone else who was another group of people who would do the maintenance they would be the ones that would send out the maintenance CDs with the updates on it. The developers would go on to something else. But in these days of web applications and constant deployments hundreds of times a day sometimes right nothing ever seems to be done. It's not just web desktop apps are picking up this model like Slack mobile apps to even games last hold out of the three phase model are now delivered over steam or downloaded to your PlayStation it could be updated continuously. Usually when it's least convenient for them to do so. So software is getting easier to change physical buildings aren't. They're still enormously expensive to change once they're constructed. So anyone ever remodeled their kitchen. Forty thousand dollars into it and all you've done is like move the sink seven inches to the right and like knock down half a wall right and even that takes eight months to finish. So there's a lot of ways right in which writing code isn't like architecting or constructing a building anymore. For one thing is not finished ever and for another the cost of making changes really isn't the same anymore we in software we work really hard to reduce the risk of getting to a situation like this to hopefully almost nothing. It's really more like our infrastructure the stuff we depend on is the buildings and we just live inside. If you think about software infrastructure a lot of it's hidden from us. Just like the steel skeleton of a skyscraper is invisible to the tenants once they move in. The heart bleed vulnerability which was announced in 2014 was basically equivalent to saying all the steel beams and all the skyscrapers you've built in the last ten years are faulty and your building might fall down. And here we are right we're residents inside of one of these apartment towers we don't depend directly on the steel beams we can't see them but suddenly our stuff is at risk because of faults in this invisible and difficult to change infrastructure. So what we create these days really isn't the buildings themselves most of our applications take space inside one of these prebuilt structures we add our stuff to it and this may feel like a bit of a downgrade right we're going from architects to what interior designers or something. But there's a lot of power in this model. The tech world is kind of like Manhattan right there's no more vacant lots. All the buildings that could be built are built sometimes new stuff gets built around the edges sometimes something big is demolished and something new put up in its place. And these buildings are the underpinnings of our applications their foundations the operating systems their parking levels the programming languages. The buildings themselves of the frameworks we've taken good ideas for structuring space in a code base and literally encoded them into our structures. And now we build our applications inside them. And the interior space that they provide for us are changeable right you can change them but it's a much larger cost than changing your code. And your choice of framework in other words the space layout that you decide to be constrained by does shape how your code base turns out. For example one might think about angular as a big open loft space with very few walls. You can do anything but you got to do it yourself. You can think about Ember JS more like a single story ranch house right with very defined rooms and you can change the purpose of any of these rooms. If you want but it's going to be a bit more work. And you can think of react is one of these like modular houses that can be assembled at the factory and then like trucked out to you and snap together. And we're building the application you have a number of different space layouts to choose from each ones optimized for something slightly different. So your stuff will probably fit in any of them. It may be a better fit in one than the other. You may need different things in different types though loft means you need to make your own sort of walls and partition the space with couches or folding screens or what have you but in a house with more actual walls you won't need to do that. So the code you end up within your application is in some ways shaped by the space you have to put it in. And there are certainly a lot of jobs in our industry that still involve working on the buildings themselves or on their foundations or on designing new buildings. But most of us build applications and as the industry expands that's largely where we're adding jobs. There was a time when making a web application meant essentially building your own house. I lived through that era like the late 90s. Every team designed their own templating system their own routing methods their own back end and front end code organization. And I did both front end and back end work in those days. Every code base was different. It's like every team tried to imagine from first principles what the ideal layout of a house would be. And sometimes you walked into a code base where all the bedrooms are in the basement and all the bathrooms are on the third floor. Right. And most of these structures really weren't up to code. These days you don't have to know how to build your own house in order to have a place to live. This is progress. And what I like about the interior space model over construction is that it makes really really plain what is hard to change and what is easy to change for you. So there's a spectrum in the house of how hard things are to change. Right. There's like rearrange the furniture replace the furniture paint the walls change the flooring out reroute the plumbing knock down a wall like way out here there's like put on a second story like it's not impossible. But that all these things exist on a spectrum of difficulty. And similarly right no code is impossible for you to change when you're writing an application. Like your code is the easiest extensions the framework slightly harder changes the programming language changing the operating system changes the hardware like all these things are possible. But not without opening up a few walls. And so when you add that together with the fact that projects aren't really ever done anymore what it adds up to you. Is that a code base isn't something we build anymore. A code base is a place where we live. And our goal isn't to finish it and move on like it would be with a structure that we build. In a place that we live our goal is to make it livable for ourselves and for all the other people who live there. And when we write code our goal isn't to finish it and move on anymore either our goal is to make it sustainable livable for the team that inhabits it. Livable in a house means you can do the things you want to do comfortably right there's a light where you want to read there's counter space for cooking there's a box tissues on the coffee table basket for the remote controls. But what's livable for a group of people depends on the people right. A livable house for two thirty somethings and a baby is different from a livable house for college age roommates which is different from a livable house for a single parent with a teenager. Livable for code works the same way it means you can make the changes and additions that you want without undue annoyance you know where things are you can find them if you want them. And just like a house what's livable for one team won't be for another. A code base that's livable for one senior developer and for junior developers is very different from a code base that's livable for five senior developers. Which is very different from a code base that's livable for one senior developer which is very different from a code base that's livable for an outsourced team. Right and so forth. And making a space or code base livable is an ongoing process people change and evolve and they come and go. Right every time you get someone new on your teams like getting a new roommate. They have this weird couch they're really attached to. So you agree somewhat reluctantly to put it in the living room. And after two days they suggest replacing all of the blinds with curtains because it's more energy efficient. And worst of all they wash their dishes with tabs instead of spaces. But you all live here now so you'll find some way to make it work. Or maybe you won't. But either way one thing to notice here is that your day to day happiness depends a lot on the people who are in the space with you. And perhaps less on the actual stuff and perhaps even less on the shape of the space itself. And show it goes with code bases right. Your happiness depends mostly on the people you work with not so much on the code and even less on your framework. But what do you do. What do you do when that interior is not livable. What do you do when your kitchen isn't this. What if your kitchen is this. Right. How on earth do you make code livable for any group of people when you're starting from here. One of the central mysteries of software development is with all the books and the blogs and the ideas about software design that are available to us all the patterns and the best practices and the rules why do so many of our code bases end up like this. So full of stuff you can hardly move around inside let alone figure out where to start to make things better. And it turns out that why people's houses end up this way is also something of a mystery. Some people say it's laziness. Some people say the same thing about code. Psychology though tells us that it's not laziness. A room like this gets this way one small decision at a time. So consider that that messy kitchen might have started out more like this. It's a small space. They tried to maximize it by adding shelves and crates making use of windowsills and other marginal space and for a while they clean it up every night. Then there's that one horrible day when they don't and then they can't face it the next morning and then when they come home they dump the groceries on top of the stove. Then that night they were to take out because they'd have to move too much stuff to get to the stove. And then the next day they put the mail on top of the groceries because there isn't anywhere else. So it's take out again and they feel bad about the state of the kitchen but it already seems so overwhelming that they don't know where to start to fix it and not long after that they get here. One small decision at a time. Compounded by despair. It's already bad. Why not just throw another piece of mail on the floor? It is the same with code bases. You walk into a file is already terrible. Half a dozen patterns that aren't working for you anymore. Product breathing down your neck for this bug fix. The totally logical thing to do is duct tape it as best you can and kind of get the hell out. Right. But all those little decisions over time are what leads to an unlivable code base. There are ways though to get out of that whole. There's a TV show that ran for a while called Hoarders. Anyone ever seen Hoarders? Okay. So it ran for six seasons despite the fact that every episode is pretty much identical. Of course that doesn't stop me from watching every single one. It's a reality TV show documenting people who had these unlivable houses to the point that someone they know requested an intervention and if they agreed then this intervention was pretty dramatic. Right. A work crew shows up their house, takes everything out of the house, throws most of it away usually, cleans the house and then returns a normal amount of like furniture and other stuff back into their house. A big bang. All that junk gone over the course of a weekend. And one of the things that struck me about the show was that there was a huge variety of stuff that people hoarded. Some folks hoarded collectibles, right. Like entire rooms full of like beanie babies. So some hoarded tools like craft supplies or garage tools. Some just trash. But there was one thing that all of the hoarded houses had and that was stacks and stacks of magazines or books or newspaper clippings about simple living. Right. This kind of thing. Beautiful photos of pristine uncluttered spaces. Advice about organizing. Suggestions for decorating. Every house had them. These people that live in those awful houses they want to be clean. They look at these beautiful clutter free houses in those magazines and they want it so badly but they don't know how to get there from what they have. And they think that the big one time event is the only way to get from something like this to something like this. And so they agree to be on the show to have their house cleaned out. All this stuff hauled away on TV not without drama. Of course this is reality television we're talking about. But they agree. They agree to be on the show. And the end of the show of course is always the big reveal the before and after shots of the filthy rooms that have been restored to some semblance of cleanliness. But I read an interview once with one of the producers of the show who said that part of the reason they stopped doing it is because they discovered that most of the people they profiled whose houses were cleaned out and all their junk hauled away most of them eventually went back to having a house that was hoarded. Happened again they made the same tiny decisions and it led back to the same result. It turns out a more effective way effective way to treat hoarding is to work with the people that live there over a long period of time changing their habits so that they clean up a little bit every time they do something. You know have the folks that live there do the cleaning. One little area at a time. Now it takes more than a weekend but it does actually dig them out of their hole and keep them out rather than artificially vaulting them out just to let them fall back in again. Unfortunately for this producer though that makes very boring reality television. Now our cluttered code bases work the same way. We fight with them day in and day out just to move around just to get anything done and we dream of the rewrite. If only we could rewrite it we wouldn't make the same mistakes. We should rewrite our jQuery soup into Enver. We should rewrite our monolith as microservices. And sometimes it works for a little while. At least long enough to make a triumphant blog post. But then the cameras stop rolling, the work crew leaves. And if you don't change the habits that got you to that frustrating place you'll end up there again. Sooner rather than later. People think it's the big mistakes that kill you. Our house is too small. We have the wrong framework. But it's not the big mistakes that kill you. It's the little ones. It's the lifestyle. It's the habits. You can do all the rewrites you want but if you don't change the little stuff that got you there in the first place you'll just end up with a tangled network of microservices just like you had a tangled network of class definitions in your monolith. Now to be clear these aren't individual habits. They're group habits. They're group norms. And this is by the way why the individual professionalism ethos of the software as craft movement doesn't work. This isn't individual developers being lazy or unprofessional. This is a team with dysfunctional group norms. Change has to come from the group. And all of your developers have to do it. And it sounds like it might be impossible. But let's talk about what it is that everyone has to do. Well, just like when you're dealing with roommates they have to do the everyday cleaning up. They have to wash the dishes they use, clean the toilet once in a while, run the vacuum, put their stuff away in the living room after they're done using it. Now there's more complicated tasks that contribute to livability that can be left to the people who are interested like reorganizing the kitchen cabinets or switching the couch in the love seat or replacing a dining room table is too big with one that fits better. But the everyday stuff that's what everyone has to do. And that means you can have a team where some people are interested in refactoring in splitting up the big classes or making new abstractions and some people who aren't. Not everyone has to be rearranging the China cabinet constantly, right? But everyone has to wash the dishes they use. Now you might say that's very interesting. Well, what should I do if my code base is already hoarded? What should I do if it's not that bad yet? But I want to make sure it doesn't get that way. All this is fine to keep it going. But how do I even get to that point? So let's look at how this manifests. So is this your team? Is your code base like a hoarded living room of legacy code with little goat trails of understanding running through the middle? Don't worry, you're not a bad person. It happens to everybody. So if you look at this problem from an engineering point of view, it screams rewrite. How could you ever organize anything in a place like this without any space? Just get it all out. Right? We talked about this. Top-down planning works great for some well-defined engineering tasks, but it doesn't work for a lot of software. And it's not because we're not engineering hard enough. It's because engineering actually doesn't work. What does work is to approach as though your code is literally an interior space occupied by people. And to understand it's the people you really need to work on. So here's how you do it in four steps. Although I cheated because one of the four steps has sub steps. But we'll get to that. And this will work for a code base in any language, in any framework. And the first thing is, don't make it worse. When you come into that terrible hoarded file, agree you will do the not terrible thing even if you don't have time to retrofit all the stuff that's already terrible. When you see someone do the terrible thing in a pull request, just remind them, this is we agreed. We're not going to make it worse. The second is to value improvement over consistency. Five books in a pile and one on the shelf is better than six books in the pile. Maybe the next time the code's touched, someone can move one more of the books over to the shelf. If you wait until you have time to move them all at once, it won't happen. And this one in particular is really hard for a lot of people because we're taught to value consistency, to have similar operations look similar, to communicate information about similarity through the structure of the code itself. But you know where that comes from? That comes from the software developer version of Simple Living Magazine. Shows you a beautiful version of a completely consistent, perfectly abstracted code base and it's so lovely. These pictures are lovely too, right? But you can't live in a place like this. The homes in those magazines, right, are ones like this that are staged to be sold are just as unlivable as a hoarded house. For example, in this room, where do you put your coat when you come in the front door? Where do you put your handbag, your messenger bag, your backpack? Where do you put your shoes? Where do you even put on your shoes or take them off? You're not going to sit on that nice couch when you're muddy and wet. And speaking of which, that's not a full-size couch, which is a trick to make the room look bigger. And where do you put a drink when you're sitting there anyway? Here's another view of the same room. There's no television. Where does the television go? What about the Xbox, the PlayStation, the cable box, the wireless access point? What about the mail, the magazines, the books? There's no bookshelves anywhere in here. Sure does look nice though. They've deliberately removed all the clutter and because clutter is personal. We need some clutter to feel comfortable, as true in code as it is in a house. And what that clutter is composed of is different for everyone. If you're into reading, maybe it's books. If you're into video games, it's game boxes and controllers. And if you're outdoorsy stuff, it's bikes and helmets and a kayak and what have you. The things that you use need to be accessible, near at hand and findable, at the very least. You need to tolerate some mess, but not too much. And our simple living magazines show us unrealistically clean code and they set the wrong goals. These are our software design books, the blogs, patterns, the rules and the rest of it. Code that follows all the rules and is perfectly consistent and abstracted is unattainable. Unless there's nobody living there. Because even if you could attain it, you can't live with it, right? Like this bedroom is super cute, but there's no place to put your clothes or plug in your phone. And the bed is basically on the ground, another trick to make the room look bigger. And your team can't live in a code base that's so abstracted where they can't find anything and they don't have any place to put anything. Both extremes are unlivable in spaces and in code. And so if you have a piece of code you don't understand and can't quite work with, there's two possibilities. Maybe it's too cluttered. It's so cluttered you can't distinguish the relevant ideas from the irrelevant ones. Or maybe it's so clean that the relevant ideas aren't even findable. And these two states can exist simultaneously in the same code base. Sometimes right next to each other. What we need is livable code in the middle of these two extremes, just like an actual livable living space is somewhere in between simple living magazine and hoarders. And that's why we need improvement over consistency. You need to be able to tolerate some mess because some mess has to exist in order to make it livable at all. OK, third one is inline everything. Stop putting in stories for refactoring or taking a week off to fix the one file. That's great but it's another big bang. What you need to do is learn how to incorporate this into the work you're doing every day. Follow the Girl Scout rule, right? Leave the campground slightly cleaner than you found it. And if you do that every single time, over time, you're chipping away. You're chipping away at that debt. And the fourth one is to liaise. I had to look this up how to spell it. Basically, what I mean by this is that you definitely need to be able to communicate with everyone about what you're doing all the time. And I don't mean that so when I say that you should inline things, I don't mean that you hide it. You know, I'm not saying you should lie about what you're doing. However, you should treat refactoring and cleaning up as part of everything you do and be open about it. I want to come back to Fred Brooks and No Silver Bullet and look at his actual thesis statement. This is an actual thesis statement. There is no single development in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, reliability and simplicity. Now I want to highlight this part. He's looking for at least one order of magnitude improvement, meaning something that improves our practice by 10 times. What he is not saying is that he's not saying incremental improvement isn't possible with tools or process. And we all know it is, right? Those of us who live through programming in the 90s know that the switch to Agile was not the Silver Bullet, but it has at least marginally improved outcomes in most cases. What he is saying here is that order of magnitude level improvement is impossible, meaning nothing within the realm of tools or process represents a useful paradigm shift. But what is the realm of tools and process? I would argue that the realm of tools and process is the realm of engineering. Brooks and the other folks who wrote software at large companies in the 80s considered what they did engineering. Of course it was. What else could it be? And they operated inside this engineering box. So Brooks looked around inside this box of what could be done within the engineering model, right? Tools, management, processing. He realized there were provable limitations. He found the edges of its usefulness. But he didn't explicitly recognize that this was a box, that there could be something outside. Now this is a classic learning curve we see over and over again in the history of science. People recognize there are problems with their existing model, but they don't yet see a new model that makes sense to them, so they continue to function within the one they know and they live with some cognitive dissonance. And that's what's going on in the No Silver Bullet paper, I realize. And that's why I find the paper so compelling. It's brilliant. And he's so close to breaking through, but he doesn't quite do it. He's expressing this cognitive dissonance, which is that he sees problems with the current model, namely that projects often aren't successful. And he is also expressing clear frustration that nothing we try breaks us out. And he is concluding, therefore, that we can't, that there's nothing else, right? But there's a whole set of stuff outside that box. He's saying we don't know how to improve software. And he's going further to say, not only do we not know how to improve it, he's saying it's not knowable. And I think he's right that that box won't offer us what we want, that thinking about software as engineering is a dead end. And we've taken it as far as we can. It's a model that's outlived, it's useless. But a shift in the way we conceive of code and how we create it will give us what we're looking for. The Silver Bullet is just outside of the box that Brooks's thinking was constrained to in the 80s. So here's where we come to the sub steps when we're talking about communication. When you want to do refactoring, don't ask for permission. This is part of your job. But be upfront about what you're doing. And on the same note, don't ask for forgiveness either. This is not something you need permission for. However, learn from all of your mistakes. Part of your job is to make these mistakes. This is what leads you to understand the problem you're working on and to understand your code base. You will make mistakes. You will overdo the refactoring sometimes and underdo it other times. But learn from it each time. Ask for advice. Do you think we should refactor this right now? However, don't always take it. Fundamentally, it's your job as a developer to decide whether or not something needs to be refactored. And you need to be able to have the freedom to make those decisions and to make those mistakes. And do work together with everyone because you have to live here. And I think that deserves its own circle, right? You have to live here. This is important. And our goal is to change the code base from one where it's you have to live here to like you get to live here. Right? That's what we want. And I've approached the question of what software is from two different directions, right? I've talked about how teams work best when they run like creative groups generating an experience, right? With the actors, the crew, the playwright, the sets, the props, costumes, the director, even the audience rather than just like an object that gets manufactured. And I've talked about how code bases work best when we think of them as a space inhabited by people, right? And their stuff rather than just the walls and the building that contain the space. And what ties these together is that they're moving the focus away from the code and towards the people. However, and over the years, I've often said on Twitter and in other places that the most important part of software is the people. I actually don't think that anymore. The most important part of software is not the code. However, the most important part of software also is not the people. The most important part of software is the system. And the more we can think about software as an interconnected system of code and people, the closer we're going to get to a breakthrough, right? The closer we're going to be to a revolution. But more importantly, the closer we'll get to a code base that we're excited to work in. And you can do this, no matter how bad it is now. You can do this. If you build trust between your team members, if you strengthen those connections, the code base follows. Thank you very much.