I was not expecting to be up here this morning. This was decided about 15 minutes ago. So I apologize for being a little nervous just now, because I had just found out that I was going to do this.

So I was up here being like, OK, I need to talk about the t-shirts and the socks and the, oh my god. OK, right. What are we talking about again? OK. So hello. Good morning. I am very disappointed, actually, that we can't have Bari here today. She's a really amazing person. And I do encourage you to check out a lot of the stuff she's written. She's done some writing that's been in the New York Times

and the Huffington Post and the Information Week and a bunch of other places. She's got some really, really interesting things to say. And I wish the travel gods had been kinder to us. So I'm going to tell you about software architecture. Bari is an attorney, and so she has some interesting things to say about that, and a former Facebook employee, a leader at Facebook.

So I'm not going to talk about social media and privacy, because I feel like I'm not super qualified. I already introduced myself this morning once, but this is me. I'm beyond what I do for Ruby Central. I'm a software architect in the UX engineering group

at Salesforce. And before that, though, I spent about half my career doing software consulting. About 10 years, if you can believe that. And before the consulting, I did a bunch of product dev work at companies of various sizes. So 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, and I think that the thread

that has tied my career together has been the community work, and that includes what I do here at Ruby Central. But I think that the thing that has impacted my career the most is RailsBridge. And that was a nonprofit that I founded in 2009 with another developer named Sarah Allen. And we were one of the first organizations

back in 2009 to offer 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 were coming back into it from some time away. And when we started 2009, right, there's no code schools. Dev Bootcamp graduated their first cohort in 2012. So there was no place to send people

that were excited about it, other than to meetups, conferences, books, the internet, kind of the traditional places. And to be honest, at the time, we weren't even really sure that there would be any women interested in learning Rails. We posted the first meetup through SF Ruby's meetup account and we thought, well, we were being sponsored

by an organization called Orange Labs and they were buying us lunch. So we thought, well, worse comes to worse, no one shows up, two of us can have lunch and talk. Then less than 24 hours after we posted the first meetup, it was completely full and had a waiting list of 125 people. We were like, okay, well, that answers that question. And our workshops are part of what helped

generate the demand for code schools because they demonstrated that there's an underserved market out there of folks that didn't come to programming through computer science, like I did, but who still had the mind for it in a very different way than I did. In doing these workshops, I met a bunch of people that took to programming immediately,

despite in some cases having never written code before. And I had been taught, though, that the way that I thought about programming, the way I approached it, which was a fairly sort of math-oriented engineering type mindset, was the only way to do it well. But here, right before me, right, were people that were clearly naturals and clearly loved it and who clearly did not have

a mathematically-oriented brain in the same way that I did, and that fed my internal sense that something was wrong with the way that we thought about software. And that suspicion had always been there. This made that voice louder. It said, somehow we're using the wrong model because it doesn't explain this.

I was trained to think about software as engineering, as architecture, as construction, as manufacturing. I mean, the very words we use for the things we create, product, they're stuck in this model, right? But there's so many things it doesn't explain. For example, if we are crafting a product of some sort, why is software never done anymore?

If we're engineering solutions, why can't we plan ahead? If we're architects or we're builders, why do so many projects just utterly fail to complete? And if computer science fundamentals are really that important, why are interviews the only time I ever need to think about runtime complexity?

And the error question, right, the question that's sort of above all of these is that with all of the advice and the best practices and the rules and the books and the conference talks about software design, why do so many code bases turn into unwieldy, unusable, unfun places to work?

Anyone ever worked in one of those? Just feels like you're slogging through molasses to get anything done. Why do so many of them turn out that way? And I felt this sort of vague sense of wrong ever since my computer science classes in college, to be honest, but it's taken me a long time

to articulate it. It's taken me an even longer time to think about what an alternative model might be. I've been doing talks around the central theme probably since about 2012. For the last few years, as I was writing code and I do a lot of pair programming with other developers, I've also been thinking about two models for software,

one for development teams and one for the code bases that they work on. And these models help us capture software as it is when it's done well. And like any good model, help us understand what to do in novel situations. And 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 actually is something called Conway's Law, which was formulated in 1967. So doing the math, it is at this point a 50-year-old idea. And what Conway's Law says is that the structure of your code will recapitulate your team's communication structure.

That sounds really abstract. But let me give you an example from an early startup plant that I had. They had a small team of five engineers. Like that transition? Cool. There we go, five engineers. Number one here was in charge.

He was CTO. He tended to broadcast information to the rest of the team. However, I mean, being such a small team and they were all in the same room, the structure was sort of functionally flat, right? Their informal lines of communication were pretty good. Their software architecture was five different services written in five different languages. Number one was the orchestrator.

But the others talked amongst themselves as well. I mean, 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 is much harder to see, but it's still there. And the reason this is so useful is because it means that if you see a problem in the code it's reflecting a problem in your communication structure.

Messiness in the code reflects messiness in your 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 you can approach it. You can make changes to your team, which drives changes to the code base.

Or you can make changes in the code base that 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 and some problems look like they're purely team based, but all of your problems are both. For example, if your code base contains

three competing implementations of logging a user in, you could consider that purely a code problem, technical debt that you need to pay down. But it also represents a communication deficit amongst the members of your team. Because if they were communicating well, you wouldn't have three different implementations of logging a user in.

And so that's why we need two models, right? The team and the code base are equally important and distinct parts of a software system. And this talk focuses on the code base side of that equation. I'll touch on the team side as well. But I've spoken about that and written about that in more detail in other locations. And we talked about Conway's Law.

I want to mention now the one other idea that has underpinned most of my thinking on software, and that is a paper from computer scientist and software engineer Fred Brooks written in 1986. It's called No Silver Bullet, Essence and Accident in Software Engineering. Brooks is better known for a book called The Mythical Man-Month that you may have heard of.

But I find this paper actually much more compelling and relevant to me. I read it probably about once a year. And the paper says, in essence, that it is not possible to create a tool or a process that makes software engineering orders of magnitude better. That there is irreducible complexity in software that does not exist in other areas of engineering

like civil engineering or hardware. Now when Brooks wrote this paper in the 80s, hardware chip speeds were doubling every 18 months. And people were sure that there's a software equivalent out there. There's something we could do that would double our productivity. But what Brooks was saying is there's something different about software. It doesn't conform to the same rules.

And therefore, there's no way to make big leaps forward. And I've been thinking about this for a long time. My gut told me he was right, but I didn't know why. I feel like I've been chipping away at this problem for the better part of 20 years. And one of the things I've talked about in the past when I'm thinking about the team is that our primary metaphor for a software team

is often something like a factory where workers are assembling a product or maybe a workshop where they're hand manufacturing a product with chisels or something. And it doesn't really fit with the way that we write software in the modern day, right? Software isn't much like a physical product that we're manufacturing anymore.

It's more like an experience. It incorporates the development team, the code, other people in our organization, even our customers. It's a group creative effort when it's done well. It feels more like a group of theater people putting together a play than a group of workers fabricating something physical. Teams are more successful when we think about them

as groups of creative people collaborating. And there's a lot of great research on how that works that you can basically read and apply word for word to your software teams. The model of thinking about us as a creative team gives us more information and it predicts more behaviors than a manufacturing model does even though many of us who work in tech

and particularly programmers are not accustomed to thinking about what we do as creative. So how do we make a similar shift in how we think about code? And for me the difficulty has always come down to this word, architecture. I think the joke's on me. When I wrote the first version of this talk

about a year ago, I only took this job at Salesforce about six months ago and now my title is architect. So I wish I could say this is ironic, but actually. So for 50 years, right, we've been told that what we do is like architecture. That the careful and methodical assembly

of software systems can be usefully modeled by the careful and methodical assembly of physical buildings. So maybe early in our careers though our job is less like architecture and more like construction. We're taking someone else's designs and we're building them. But for 50 years, right, being an architect has been the end goal, even if we don't call it that, even if we make fun of the word.

At least on sort of an individual contributor non-manager path, right? That's what we want to be when we grow up. We want to be the person who makes the models, who makes the plans, who hands them off to people earlier in their careers to build them. This is Zaha Hadid who is an extremely influential Iraqi-British architect who is largely responsible for bringing curves into modern architecture. I mean, she's a badass.

Who wouldn't want to be her, right? But the problem, right, the problem in our thinking about software this way, and that doesn't really reflect how it works anymore. Creating a building actually has three very defined phases, planning, construction, and then maintenance. So there's a different group of people doing each one. First the architects have at it, then they hand off to the construction folks

who then hand off to the facilities folks. And software projects used to look a lot like that. Software projects used to be done eventually. You know, 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 up to a different set of people to do maintenance and go on to something else.

But in these days of web applications and constant deploying, sometimes hundreds of times a day, nothing ever seems to be done. And it's not just the web. Desktop apps have picked up this model, mobile apps, and even games, which for a long time were the last holdout of a very traditional three-phase model, are now delivered over Steam or downloaded to your PlayStation and can be updated continuously,

usually when it's least convenient for them to do so. So software is getting easier to change. The same cannot be said of physical buildings, of course. They're still enormously expensive to change once they're constructed. Anyone who has ever priced out remodeling their kitchen?

Anyone? You might know what I mean. $40,000 later, all you've done is move the sink seven inches to the right and knock down half a wall. And even that takes eight months to finish. Software's never finished, plus the cost and expense of changing a building don't really reflect the cost and expense of changing software anymore.

We're now in a world of small changes. We've tried to reduce the risk of change so that we are very unlikely, in an ideal world, to end up in a situation like this. It's really more like our infrastructure, the stuff that we depend on is the buildings and we just live inside.

You think about software infrastructure, a lot of it's hidden from us, right? Just like the steel skeleton of a skyscraper is usually invisible to the tenants once they move in. If you remember the Hartley Vulnerability, which was announced in 2014, that was basically equivalent to saying that all the steel beams and all the skyscrapers you've built in the last 10 years are faulty and your building might fall down, sorry.

Our applications are like residents of one of these apartment towers. We don't see the steel beams. We don't see open SSH very often. But suddenly our stuff can be at risk because of the faults in the invisible and difficult to change infrastructure. So maybe what we make these days isn't the buildings themselves. Most of our applications take space

inside of one of these pre-built structures and we add our stuff to it. And this may feel a bit like a downgrade, right? Are we going from architects to interior designers maybe? Not quite. There's a lot of power in that model. Tech world, I think of sort of like Manhattan, right? Most of the buildings that could be built are built. There's no more vacant lots. Sometimes new stuff gets built around the edges.

Sometimes something big is demolished and something new is put up in its place. These buildings are the underpinnings of our applications. Their foundations are the operating systems. Their parking levels are the programming languages. Buildings themselves are the frameworks. We've taken our good ideas for structuring space in a code base and encoded them in our structures. And now our applications are built

inside of those structures. And the buildings, the interior space they provide for us are changeable but at a much larger cost than changing our code. In your choice of framework, right? In other words, the space layout you choose to be constrained by does shape how your code base turned out. You might think of, for example, AngularJS

as a big open loft space with very few walls. You might think of EmberJS more like a single story ranch house with very defined living spaces that are labeled. And you might think of React as a newfangled set of modular homes that can be assembled at the factory and trucked out to you and snapped together.

And when we're building an application, we have a number of different space layouts to choose from. Each one is optimized for something slightly different. And your stuff, right, the application you wanna create will probably fit in whichever framework you choose. It may be a better fit in one or the other. And you may need different things in the different types, right?

A loft means you need to make your own walls. You need to partition the space with couches or folding screens or bookshelves or whatever. And in a house with more actual walls, you don't need to do that. And the code you end up with in your applications is in some ways shaped by the space that you have to put it in. Now of course there's certainly still jobs

in our industry that involve working on the buildings themselves or on their foundations or on designing new buildings. But most of us, especially here at a place like RailsConf, we build applications. And as the industry expands, that is largely where we're adding jobs. There was a time when making a web application meant essentially building your own house.

Every team designed their own templating system, their own routing methods, their own backend, frontend code organization strategies. I lived through that era. Doing both frontend and backend work and every code base was different. It was like every team tried to imagine from first principles the ideal layout of a house. And sometimes that meant all the bedrooms were in the basement for some reason while all the bathrooms were on the third floor.

Most of the structures were not 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 and that is progress. I really liked how David put it in his opening keynote. I like the idea of conceptual compression. There are things that you don't have to think about

anymore because they're inside the walls of your house. Instead all you need to think about is how to lay out the furniture inside. And what I like about the interior space model over something like a construction model is it makes it very plain what is hard to change and what is easy to change for you. There's a spectrum in a house about how hard things are to change, right?

Rearrange the furniture, pretty easy. Replace the furniture, all right, all right, fine. Paint the walls, okay we're getting a little more complex. Change the flooring, a bit harder. Move the electrical outlets, okay getting tricky. Re-route the plumbing, knock down a wall, put on a second story, add a garage.

Nothing's impossible and no code is impossible for you to change when you're writing an application but some's easier to change than others and your code that runs your application is the easiest thing for you to change. Extensions of the framework, harder. Changes the programming language, the operating system, all these are possible but not without opening up a few walls.

When you add that together with the fact that projects are never done anymore, so what it adds up to is that a code base really isn't something we build anymore. It's a place where we live and our goal isn't to finish it and move on like it would be with the 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. When we write code, our goal isn't to finish it and move on our goal is to make it sustainable, livable for the team that inhabits it. What does livable mean? Livable in a house means you can do the things you wanna do comfortably. There's light where you wanna read, there's counter space for cooking,

your spices are accessible, there's a box of tissues on the coffee table, a basket for the remote controls. But what's livable for a group of people depends on the people, right? Livable for two 30-somethings and a baby is different from what's livable for college age roommates which is different from what's livable 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 wanna make without undue annoyance. You know where things are, you know where you can find them. And just like in a house, what's livable for one team won't be livable for another. Livable for one senior developer and four junior developers is different from livable for five senior developers, is different from livable for one senior developer

which is different from livable for an outsourced team and so forth. And so making a space or a code base livable is an ongoing process. People change and evolve and they come and go. Every time you get someone new on your team it's like getting a new roommate. They have this weird couch they're really attached to.

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 in a code base depends a lot on the people who are in this space with you. Perhaps less on the actual stuff that's in there with you. And perhaps even less on the shape of the space itself. And so it goes with code bases. Your happiness depends mostly on the people you work with.

Somewhat less on the code and even less than that on the framework that you pick. But what do you do when the interior isn't livable at all? What do you do when your kitchen isn't this? What if your kitchen is this? How on earth do you make code livable for any group of people when you're starting from something like this?

And I know many of us are. One of the central mysteries of software development which I touched on before is that with all of the books and the blogs and the ideas and the thought leadering conference docs available, 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 tells us though that it's not laziness. A room gets like this. One small decision at a time. I consider that messy kitchen

that we were looking at before might have started out something more like this. It's a small space. They've tried to maximize it by adding shelves and crates, making use of window sills, other marginal space. For a while they clean it up every night but then there's that one horrible day when they don't and they can't face it the next morning and then they come home. They dump groceries on top of the stove and then that night they order takeout 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 takeout 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 too long after that they end up here. One small decision at a time compounded by despair. It's already bad. Why not throw another piece of mail on the floor?

And it's the same with code bases. You walk into a file that's terrible. Half a dozen patterns that aren't working for you anymore, product is breathing down your neck for a bug fix. The totally logical thing to do is duct tape it as best you can and get the hell out. But all those little decisions over time are what leads to an unlivable code base. There are ways though to get out of that hole.

There's a TV show called Hoarders. Has anyone ever seen that TV show? It's not on anymore. It ran for six seasons despite every episode being basically identical which of course didn't stop me from watching every single one. The show was a reality television show documenting people who had these unlivable houses

to the point that someone they know requested an intervention. And if the person agreed then this intervention was pretty dramatic. A work crew would show up at the house, take everything out, often throw most of it away, clean the house and return a normal amount of furniture and other things back into the house. Big bang, right? All that junk gone over 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 like Beanie Babies, entire rooms of Beanie Babies. Some hoarded tools, some just trash. But there's one thing that all of the hoarded houses had in common and that was, as this picture might imply,

stacks and stacks of magazines, books and newspaper clippings about simple living. This kind of thing, right? Beautiful photos of pristine, uncluttered spaces, advice about organizing, suggestions for decorating. Every house had them.

These people that live in these 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 a big one-time event is the only way to get from someplace like this to something more like this. And so they agree to be on the show, to have their house cleaned out and all their stuff hauled away on television,

not without drama, of course, because this is reality TV, but they agree. And of course, the end of the show is always the big reveal, the before and after shots of these filthy rooms that have been restored to some semblance of cleanliness. But I read an interview with one of the producers of the show once who said that part of the reason they stopped doing it

was that they discovered that most of the people that they profiled whose houses were cleaned out and all their junk hauled away, most of them eventually went back to a hoarded house. It happened again. They made up the same tiny decisions and it led back to the same result. It turns out that a more effective way

of treating hoarding is to work with the people who live there over a long period of time, changing their habits so that they clean up a little bit every time they do something. And you have the folks who live there do this, one little area at a time and it takes more than a weekend but it actually does dig them out of their hole and keep them out rather than artificially vaulting them out

just so that they can fall back in again. And fortunately for this producer, that makes really boring reality television. 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 if only we could rewrite it. We wouldn't make the same mistakes.

We should rewrite our jQuery soup into Ember. We should rewrite our monolith into microservices. And sometimes it works for a little while, right? At least long enough to make a triumphant blog post. Then the cameras stop rolling, the work crew leaves and if you don't change the habits that got you into that frustrating place, you'll end up there again, usually sooner rather than later.

People think it's the big mistakes that kill you. Oh, we picked our own framework and moved into a house that's too small. It's not the big mistakes, it's the little stuff. 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. And to be clear, the habits I'm speaking about are not individual habits. They're group habits, they're group norms. And this is why, by the way, the individual professionalism ethos of the software as craft movement has never resonated with me and in fact does not work. This is not individual developers being lazy

or unprofessional, this is a team with dysfunctional group norms. Change has to come from the group. And all your developers have to do it. But what is it that everyone has to do? Well, just like when you're dealing with roommates, they have to do the everyday cleaning up. They need to wash the dishes they use, clean the toilet and the bathtub sometimes,

run the vacuum now and then and put away their stuff from the living room when they're done using it. Now there are other things one can do in a house to make it livable, more complicated tasks such as reorganizing the kitchen cabinets, switching the couch and the loveseat, replacing a dining room table that's too big with one that fits better. And you can leave that to the people that are interested in doing it.

Not everyone has to do that part but everyone has to do the everyday stuff. And in a code sense, what this means is you can have a team where some people are interested in refactoring and splitting up the big classes and making abstractions and some people aren't. Not everyone has to be rearranging the China cabinet constantly. And in fact, it's probably better if you don't.

But everyone has to wash the dishes they use. Now you might say, okay, this is very interesting, what should I do if my code base is already hoarded? What should I do if it's not that bad yet? I want to make sure it doesn't get that way. It's fine to keep it going but how do you even get to that point? So I want to look a little bit more closely at how this manifests.

Is this your team, is this your code base? Hoarded living room of legacy code with little goat trails of understanding running through it? Well don't worry, you're not a bad person, it happens to everyone at some point. Now if you look at this problem from an engineering point of view, a code base like this screams rewrite. Big bang, how could you ever organize anything

in a place like this without any space? Get it all out. But we talked about this, right? Top down planning works great for some engineering tasks and it works great for some software. But it doesn't work for a lot of software. It doesn't work for the software that most of us write. And it's not because we're not engineering hard enough, it's because engineering actually doesn't work.

It's not the right model. What does work is to approach it as though your code is literally an interior space occupied by people. And understand that it's the people that you need to work on. So here's how you do it in four steps. I sort of cheated, one of the steps has sub steps. But this will work for a code base in any language, in any framework.

The first rule is don't make it worse. When you come into that terrible hoarded file, agree that you will do the not terrible thing even if you don't have time to retrofit all the stuff that is already terrible. And when you see someone do the terrible thing in a PR, remind them you agreed not 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 next time this code is touched, someone can move one more of the books over to the shelf. But if you wait until you have time to move them all at once, it will never happen. Now this one in particular is really hard

for a lot of people. We are taught to value consistency, to have similar operations always look similar and to communicate information about similarity through the structure of the code itself. And you know where this comes from? Comes from the software developer version of this.

All these books and these blog posts, they show you the beautiful vision of a completely consistent, perfectly abstracted code base. And it looks so lovely. I mean look, they have melons just sitting there on a chair, I guess. Everyone likes melons.

But you can't live in a place like this. Right, the homes in those magazines are ones like this that's staged, they call it, to be sold, are just as impossible to live in as a hoarded house is. For example, in this room, where do you put your coat when you come in the front door?

Where do you keep your handbag or your messenger bag or your backpack? Where do you put your shoes? Where do you even put on your shoes or take them off? You're not gonna sit on that ice couch when it's muddy and wet. Speaking of which, that's not a full-size couch. It's 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 looking from the front door. There's no television, where does that go? What about the Xbox, PlayStation,

cable box, wireless access point? What about mail, magazines, books? There's no bookshelves anywhere in this house. It sure does look nice. They've deliberately removed all the clutter and that's because clutter is personal. We need some clutter to feel comfortable. What that clutter is comprised of is different for everyone.

If you're into reading its books, maybe if you're into video games, it's game boxes, controllers. If you're into outdoorsy stuff, it's bikes and helmets and a kayak or something. But the things that you use and the things that you need to be accessible and near at hand, they need to be findable at the very least. You need to tolerate some mess but not too much. And it's the same in code bases.

In our code, we have our simple living magazines too that show us unrealistically clean code and they set the wrong goals. These are our software design books, our blogs, our patterns, our rules, 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 couldn't live with it. Like this bedroom is super cute but there's no place to put your clothes or plug in your phone. The bed is basically on the ground, which is another trick to make the room look bigger. Your team can't live in a code base so abstracted that they can't find anything and that they don't have any place to put their stuff. Both extremes are unlivable in spaces and in code.

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 so cluttered that 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 in the same file.

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 magazines and hoarders. And if you're striving for consistency, what you're striving for is the unrealistically clean version.

What you want is improvement. The third rule is inline everything. No more stories about refactoring the user class. Do that refactoring inline while you're executing on stories that actually have business value. Now I'm not talking about taking five extra days on a two day story just to do a big restructuring. Just if it's gonna take a few hours, just do it.

Do the easy things. Do the things you see. Those things will make the big problems smaller. It's like clearing away the vines from an old door. You clear away enough of them and you see the outline. But if you think you see the outline and you try and do it all at once, it's not gonna work. Eventually the big problems will be small if you take care of the small problems you see.

Now I often get a lot of pushback on this one because people are afraid of reducing their perceived speed. But I would put it to you that it takes less time overall to do it if you do it while you have the context. Rather than putting it off and having to regain the context when you pick up the refactoring story if you ever do.

And the fourth rule is to talk more to everyone. Now for the introverts in the room, this doesn't have to be talking in person. Although that's still the highest bandwidth form of communication that we have. But it can be in Slack or in email or whatever medium you're comfortable in. But do it. Talk more to people. The people who monitor your speed, whether that's managers or your product folks or whoever it is, they need to understand why you're doing this.

You may be starting to take over decisions that they've seen as theirs. Such as whether to do refactoring now or wait until later. And this can be a tricky political territory. So let me break this advice down a little bit. First is don't ask for permission to clean up small pieces of code.

But be upfront about what you're doing. And the second is don't ask for forgiveness either. This is part of your job. But what that means is you do need to learn from your mistakes. Doing all this stuff on your own is what's gonna give you the sense of when is the right time to do it

and when it's not. And sometimes you're gonna do it at the wrong time. Or sometimes you're gonna skip one that you should have done. But learn every time. Then do ask for advice. Ask for advice about do you think right now is the right time to do this refactoring?

Because you do wanna make this a collaborative process. But don't always take the advice. But do ask for it. You wanna know what they think. And finally, do work together. Because you have to live here. You have to live here together.

And the goal here, of course, is to make the code base from a place where you have to live to a place where you get to live. And over time, that's what these techniques do. They can move you out of a hoarded house into a place you enjoy being in. And given how much time you spend in your code base, they're well worth the investment. I wanna come back to Fred Brooks'

actual thesis statement in his paper called No Silver Bullet. There's no single development in either technology or management technique which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, and in simplicity.

I wanna highlight this part. He is looking for at least one order of magnitude improvement, meaning something that improves our practice by 10x or more. What I wanna point out is that he is not saying that incremental improvement isn't possible by tools or process. We know that. Those of us who lived through programming

in the 90s know that the switch to Agile, while it has not been the magic wand that everyone was hoping for, has in most cases at least marginally improved outcomes. So what he is saying is that order of magnitude level improvement isn't possible, meaning nothing within the realm of tools or process represents a useful paradigm shift,

because that's what a 10x change is. It's a 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 of this engineering box, and Brooks looked around inside this box at what could be done within it, which is tools and management and process, and he realized there's provable limitations. There are edges. He found them. But he didn't explicitly recognize, necessarily, that this was a box,

that there could be something outside, that there was bits of software, and in fact, the vast majority of software that we see today, that operates outside of this box. And that's a classic learning curve that we see over and over again in the history of science. People recognize that 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 now, that's why I found it so compelling. It's brilliant, and he is so close to breaking through, but he can't, right? He's expressing this cognitive dissonance, and he sees problems with the current model, that projects aren't successful, and he is also expressing clear frustration that nothing we try breaks us out,

and therefore, he concludes that it is not possible to break out. We don't know how to improve software, is what he was saying, and he's going further and saying that we don't know, and it's unknowable. And he's right, I think, that this box is not gonna offer us what we want.

Thinking about software as engineering was extremely useful to us for the last 50 years, but we've taken it as far as we can, and it's outlived its usefulness. A shift in the way that we conceive of our code and how we create it will give us what we're looking for. There is a silver bullet, it's just outside of the box that Brooks was thinking within.

I've approached the question of what software is from two different directions now. I've talked about how our teams work best when they're run like creative groups generating experience, like a play that incorporates the actors, but also the crew, the playwright, the set, the props, the costumes, the director, even the audience,

rather than just merely as the object that gets manufactured. And I've talked about how our code bases work best when we think about them as a space inhabited by people and their stuff, rather than just the walls and the building that contain the space.

And what ties these together is they're moving the focus away from the code towards the people, because as it turns out, the important part about software is not code. I feel like we've figured this out at this point. However, in my opinion, the important part about software is not the people either.

And this is a mistake that I have made as I have tried to move my thinking past the code, is that I have, in many times in the past, asserted that the people are the most important part of software, but I no longer believe that that's true. The important part of software is the system. It's the code and the people together, and they are not separable.

The more we can think about software as an interconnected system of code and people, the closer we'll get to a breakthrough. The closer we'll be to a revolution, to a paradigm shift. And most importantly for us, perhaps, the closer we'll be to be able to build code bases that we're excited to work in.

Because Fred Brooks was right. We're not like other engineering disciplines, and if there is a silver bullet, it lies in conceiving of software development as something entirely new. It lies in stepping outside the framework that Brooks and Conway and everyone else have been viewing our job through for decades. And when we do that, suddenly we have the tools we need to improve a problem that has plagued

software development since its inception. And you can do this. No matter how bad it is now, you can do it. And notice that the four steps, there was nothing in there about tools. There was nothing in there about code. There was nothing in there about the size of your models. It's all about the people.

Build trust between team members and strengthen those connections. The code base will follow. Thank you very much.