I've had a really, really great time the last couple of days. How have you guys found it?

That's a lot of energy for five o'clock. Good job. I'm always impressed by the conferences that Lea and Crystal and the rest of the people put on, so before we go any further, I'd like to have a round of applause for the organizers.

As Lea mentioned, I have been doing a lot of conferences, and so I've seen a huge variety of conferences and different ways to run them. And EmberConf continues to be one of the best-run conferences that I've attended.

And while we're on that topic, I'd also like to say thanks to them for arranging for my mom to get a pass to come and see my talk today. She has never seen me give a talk before, and so I'm very excited about that.

And finally, thank you so much to all of you folks, because I was a little bit nervous coming into the Ember community. I have, as Lea said, been mostly in the Ruby and Rails side of things, and so I didn't really know what the community had evolved into. I did an Ember project in mid-2012,

which, in Ember terms, is a long time ago. And it's been great, actually, for the last couple of days to load into my brain all of the stuff that has happened since then and the way that Ember has changed and where it's going. And that was, it's been really interesting, it's been really great, and everyone's been so friendly. It's very nice.

I do, as Lea mentioned, I do a lot of Ruby and Rails, mostly as a consultant, and inevitably, because they're Rails code bases, I do end up doing a reasonable amount of JavaScript. My community work, however, has mostly been on the Ruby side. I'm one of the directors of Ruby Central. We put on RubyConf and RailsConf.

I'm on the board of Ruby Together. We raise money to fund development work on some of our critical infrastructure projects. In 2009, I founded RailsBridge, which is one of the first workshop-oriented efforts to bring more women specifically into a community. And since then, it's been, that idea has been taken and expanded upon, and now we have a closure bridge, Scala bridge,

Elm bridge, all kinds of neat stuff. And recently, we set up a nonprofit called Bridge Foundry to be an umbrella organization for all of those efforts so that if a new technology wants to use the bridge model, they don't have to figure out how to set up a nonprofit before they can do their first workshop.

So I'm excited about that. On the technical side, I see a lot of different code bases. I tend not to do greenfield projects anymore. I used to for a while. Instead, I tend to work with existing teams who are trying to grow, but are finding that their code base doesn't support the type of growth that they wanna do.

And one of the things that's been interesting to me about this is that there's a word that we use a lot when we talk about our code. That word is architecture.

For a better part of 50 years, we have compared software to construction, to building things. And we've been told that what we do is architecture. Maybe early in our career, what we do is construction. We take someone else's designs and we build them. But our end goal, in theory,

at least on sort of the individual contributor, non-manager path, has been to be an architect. We wanna be the person who makes the models, makes the plans, hands them off to people earlier in their careers to do the building. But there's a problem in our thinking about software this way,

as building something, and that is that it doesn't really reflect how it actually works anymore. I was super excited over the course of the last few years to hear several of the other speakers reference Fred Brix's paper from 1987 called No Silver Bullet, Essence and Accident in Software Engineering. This bit.ly link will take you to the PDF.

I read this paper probably about once a year. And I find it more compelling and more relevant to me than the Mythical Man month, which is the book that he is better known for. And the paper says, in essence, that it is not possible to create a tool or a process that makes developing software orders of magnitude faster,

that there is irreducible complexity in software that doesn't exist in other areas of engineering, such as in hardware, where at the time he wrote the paper, chip speeds were doubling every 18 months, and people were looking for the software equivalent of that. But there is something different about software from every other sort of engineering.

And No Silver Bullet is probably one of the two ideas in software that have had the largest impact on the way that I think about how teams make software. And today I want to start off by talking about the other one. The single most useful thing that I have ever learned about how to make a software team effective is called Conway's Law.

This bit.ly link will take you to the paper that was written in 1969. Conway's Law says that your code will recapitulate your team's communication structure. And I'll give you an example that I saw early in my consulting career with a startup client.

They had a small team of five engineers. Number one here was sort of nominally in charge, tended to broadcast information to the rest of the team. But being so small, the structure was functionally flat. Their informal lines of communication were also quite good. Their architecture was that they had

five different services written in five different languages, by the way. Number one was the orchestrator. But the others sort of talked amongst themselves as well. And so their code literally reproduced their org chart. Now when you have a team who's all working

in the same code base, this can be harder to see, but it's still there. And the aha moment for me was realizing that that means that if you see a problem in your code, it's reflecting a problem in your communication structure. So you have two avenues to approach any problem. You can make changes to the team,

which will drive changes to the code base, or you can make changes to the code base, which will drive changes to the team. And for any given issue, you can do either one or both, depending on which one seems more effective. And certainly, you have to consider both in your solutions. And a central question in my career has been

why does so much advice about making good software fail more often than it succeeds? I was involved in a lot of projects early in my career. Some of them went well, some of them didn't. It seemed mostly random. Sometimes the ones with horrible code did fine. Sometimes the ones with good code did fine. Sometimes the ones with good code

had nothing to do with anything else. And so I started to wonder why is it that all the advice we get about software design, process, why is it that none of that seems to matter in some ways? And when I was younger, the way that I put this was

why does software suck so much? These days, I tend to think about it more like this. How can we make more software projects successful? And how can we make the projects we have more successful? How can we make this, how can we make our practice more effective, more humane, more diverse,

more innovative, more sustainable? In general, just better. Because this is not a zero sum game. We can have all of these things. It's not an easy problem, but we do have the tools to solve it. And just like any other problem involving code, we have two directions we can come at it,

given Conway's law, right? And part of the solution here is letting go of our attachment to our architecture, building, construction metaphor, and embracing the fact that what we do, as Fred Book pointed out, is fundamentally different. Last year, I did a talk at Brighton Ruby called The Way We Write Software, which comes at this question from the team side of things.

And a few days ago, as I was working on this talk, I realized that this talk is the counterpoint to that. This talk comes at this question, but from the code point of view instead. My Brighton Ruby talk covered things like how should we think about teams of people who write software, as opposed to teams of people who build a structure or work on an assembly line

or craft something in a workshop. And in this talk, I want to explore what it means to let go of the architecture, construction metaphor when we're talking about our code base. Of course, you don't need to have seen that talk to get anything out of this one, but if it's something you're interested in, you can check that out later. There is a video, I believe, available online.

So creating a building has three very defined phases. There's the planning phase. There's the construction phase. And then finally, there is the maintenance phase. And software projects used to look a lot like that. Software projects used to be done eventually.

Remember that? You'd finish it, you'd press it onto CDs, and you'd mail it to your customers. And then the developers would hand off the project to a different set of people to do maintenance and go on to do something else. But in these days of web apps and continuous deployment,

I think it was Ingrid yesterday who said her company deploys code hundreds of times a day. Nothing ever seems to be done. Desktop apps are picking up this model. Mobile apps are picking it up. Even games, the last holdout of the three phase model, are now delivered over Steam or downloaded onto your PlayStation, updated continuously.

Change is relatively cheap. Buildings, on the other hand, are enormously expensive to change once they're constructed. Anyone who has ever priced out remodeling their kitchen knows what I mean. $40,000 later, all you've done is move the sink six inches to the right and knock down half a wall.

And so it is with software infrastructure as well. Our infrastructure is expensive and hard to change. The HeartLead vulnerability, which came to light in 2014, was basically equivalent to saying all the steel beams and all the skyscrapers you've built in the last 10 years are faulty and your building might fall down. And our applications are like residents of one of these apartment towers.

We don't depend directly on the steel beams, necessarily. At least we don't see them. But suddenly our stuff is at risk because of faults in the invisible and difficult to change infrastructure. And what this has shown me is that what we create these days really isn't the buildings. Most of our applications, it's more like the space inside,

one of these pre-built structures. We add our stuff to it. The tech world's kind of like Manhattan, right? All 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, right? The parking levels are the programming languages.

The buildings themselves are the frameworks. We've taken good ideas for structuring space in a code base and we've encoded them in our structures, in our frameworks. And now our applications that we build live inside of those structures. The buildings and the interior space that they provide for us are changeable, right?

But at much larger cost than changing our code. Your choice of framework, in other words, the space layout that you choose to be constrained by, does shape how your code base turns out. One might think of AngularJS as a big open loft space with very few walls. Whereas EmberJS might be a single story ranch house.

And React might be one of those newfangled modular homes that can be assembled in a factory and like trucked out to your lot, snapped together. When we're building an application, we have a number of different space layouts to choose from. Each one's optimized for something slightly different. Your stuff.

The application you wanna create will probably fit in whatever one you choose. It may be a better fit in one than the other. You may need different things in different places. If you pick a loft space, you'll need to make your own sort of walls, right? Partitioning the space with couches or folding screens or something. In a house with more actual walls, you don't need that, but the cost is that it's less flexible.

So the code you end up with in your application is in some ways shaped by the space you have to put it in. And there are certainly still jobs in our industry that involve working on the buildings themselves or on the foundations, designing new buildings, but most of us build applications. As the industry expands, that is largely where we are adding jobs.

Over the last two days, one of the things that I've noticed is that I may be the oldest attendee at this conference, which is kinda awesome, actually, because it means I can tell stories and no one can contradict me.

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 and 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 that all the bedrooms were in the basement and all the bathrooms were on the third floor. And most of those 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, which is progress. Our code conforms to the contours of its enclosing space. Now you might say it's always been like this, right? But an operating system conforms to the contours of the hardware that it runs on. And a compiler for a programming language has to conform to the contours of the operating system and the framework to the programming language and so on.

So you could argue that what we're doing is still building. We're building on top of the frameworks, we're adding stories to a building maybe where the lower stories are the framework. The problem with that though is it doesn't incorporate this idea of changeability. What I like about thinking about our applications as interior space rather than the exterior space

is that it makes it very plain what is hard to change and what is easy to change for you and your application. There's a spectrum in a house of how hard things are to change. Rearrange the furniture, replace the furniture, paint the walls, change the carpet,

move the electrical outlets, reroute the plumbing, knock down a wall, put on a second story. I mean no code is impossible for you to change when you're writing an application but some is easier to change than others. Your code that runs your application obviously is the easiest, extensions to the framework are harder, changes to the programming language, the operating system,

these are all possible but often not without opening up a few walls which goes along with the other shifts that we talked about which is that projects never seem to be done. There used to be a very stark difference between development and maintenance. Sometimes they weren't even done by the same people and these days that line is very often blurred.

And what all of this adds up to 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 as it would be with a structure.

In a place that we live, our goal is to make it livable for ourselves and for all of the other people who live there. And when we write code these days, generally our goal isn't to finish it and move on. Our goal is to make it sustainable, livable, for the team that inhabits it. And livable in a house means you can do things you want to do comfortably. There's a light where you want to read,

there's counter space for cooking, your spices are accessible, there's a box of tissues on the coffee table, there's a plunger near the toilet and a basket for the remote controls. And what's livable for a group of people depends on the people, right? Livable for two 30 somethings and a baby is different from livable for college age roommates, is different from livable for a single parent with a teenager.

And livable for code works the same way. It means you can make the changes and additions that you want to without undue annoyance. You know where things are, you can find them when you want them. And just like with a house, what's livable for one team won't be livable for another. What's livable for one senior developer and four junior developers is different from livable for five senior developers,

and that's different from what's livable for one senior developer, and that's different from what's livable for an outsourced team, and so forth, right? And making a space or a code base livable is an ongoing process. It's not something you do once. 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.

New roommate has this weird couch they're really attached to, and after two days, they suggest replacing all the blinds with curtains because it's more energy efficient, and worst of all, they wash their dishes with tabs instead of spaces. That joke is courtesy of Mike North, by the way.

But you all live here now, so you'll find some way to make it work, or maybe you won't. Either way, one thing to notice here is that your day-to-day happiness in a space depends a lot on the people who are in the space with you and perhaps less on the actual stuff or the shape of the space itself. So it goes with code bases.

You can't fix a communication problem by switching your JavaScript framework. So perhaps I have managed to convince you that while the exterior of the building is what everyone sees as the interior that matters more to you, the developer, who's living in it, but what do you do when that interior is unlivable? What do you do when your kitchen isn't this?

It's more like this. One of the central mysteries of software development is that with all the books and the blogs and the ideas about software design that are available to us with all the patterns and best practices and 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 if you wanna make things better. Some people have suggested that there's morality at play here or professionalism or intelligence that developers who let a code base get like this are lazy or amateur. This is what I find a bit off-putting about a lot of the writing from the software craftsman movement.

They're very heavy with these suggestions that if you just cared more, if you looked at your work as a craft, your code bases wouldn't get this way. And these people are very sincere. But I've seen some of the code bases they've worked on. And clearly there exist situations for which no amount of caring is enough.

And it turns out, actually, that why people's houses end up this way is also something of a mystery. Psychology has studied and has not actually been able to come up with super effective treatments for this problem. And at the same time, right, the way that people's houses get this way

is also extremely clear. It gets this way one decision at a time. And that sounds glib. But consider that the messy kitchen might have started out more like this, right? A small space where they've tried to maximize it by adding shelves and crates and making use of window sills and other marginal space. And for a while they clean it up every night, but then there's that one horrible day when they don't. They can't face it the next morning.

They come home, they dump their groceries on top of the stove. That night they order takeout because they have to move too much stuff to get to the stove, and the next day they put the mail on top of the groceries because there isn't anywhere else. So it's takeout again. 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. It's one small decision at a time,

and the compounding interest of despair. And it's the same with code bases. You walk into a file, it's already terrible. Half a dozen patterns that aren't working for you anymore. Product is breathing down your neck for this preg fix, and 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 used to be a TV show here in the States called Hoarders that ran for six seasons, despite every episode being basically the same. And it was a documentary about people who had these unlivable houses, right? To the point that a family member or friend requested an intervention, and the intervention was usually pretty dramatic. Work crew shows up at the house, takes everything out,

often throws most of it away, cleans the house, and returns a normal amount of furniture and other things back into the house. Big bang, right? All that junk gone over the course of a weekend. One of the things that struck me about that show was that there was one thing that every single hoarded house had, and that was stacks and stacks of magazines and 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 single house had them. These people want to be clean. They look at these beautiful clutter-free houses in the magazines and they want it so badly, but they don't know how to get there from what they have

and so they think that a big one-time event is the only way to get from something like this to something more clean. And so they agree to be on the show, not they agree to have their house cleaned out on television, and all their stuff hauled away, not without drama, of course, because this is reality television. But they agree, and of course the end of the show

is the big reveal, the before and after shots of the filthy rooms restored to cleanliness. But I read an interview with one of the producers of the show once who said that the reason they canceled it, one of the reasons, was that they discovered that most of the people they profiled, whose houses were cleaned out and their junk hauled away, most of them eventually went back to having a hoarded house.

It happened again. They made the same tiny decisions and they ended up with the same result. And it turns out that a much more effective, but unfortunately less television-friendly way to treat hoarding is to work with people over a long period of time on changing their habits so they clean up a little bit

every time they do something. Have them do the cleaning, one little area at a time, it takes more than a weekend, but it does actually dig them out of their hole and it keeps them out rather than artificially vaulting them out just so they can fall back in. Unfortunately for the producer, it makes really boring reality television. And our cluttered code bases kind of work the same way, right? We fight with them day in and day out

just to move around, just to get anything done. And we dream if we could only rewrite it, we wouldn't make the same mistakes. We should rewrite our jQuery soup into Ember. We should rewrite our monolith as microservices. And sometimes it works for a little while, right? At least long enough to make a triumphant blog post.

But then the cameras stopped rolling and 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. And sooner rather than later. People think it's the big mistakes that kill you. We chose the wrong framework, our house is too small, but it's not, 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 hoarded house in Ember just like you had a hoarded house in your jQuery page objects. And to be clear, these aren't individual habits that I'm talking about when we come to code bases. They're group habits, group norms. And this is why the individual professionalism ethos

of the software as craft movement doesn't really work. It has to come from the group. And all your developers have to do it. And what is it specifically that everyone has to do? Well, it's 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. They need to wash the toilet in the bathtub once in a while, run the vacuum here and there, put their stuff away in the living room once they're done using it. There's more complicated tasks that contribute to livability that can be left to the people who are interested in it. Things like reorganizing the kitchen cabinets or switching the couch with a loveseat or replacing a dining room table that's too big with one that fits better. But the everyday stuff, that's one,

that's the thing that everyone has to do. And in code terms, that means that you, the developers, need to make three paths amongst yourselves. And the first is you need to decide to not make it worse. When you come into that shitty file, agree that you will do the not shitty thing. Even if you don't have time to retrofit all of the stuff that is already shitty.

And when you see someone do that thing in the PR, remind them of your agreement not to make it worse. Secondly, you need to value improvements over consistency. Five books in a pile and one on the bookshelf is better than six books in the pile.

Maybe next time the 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, it won't happen. This one is really hard for a lot of people. Because we've been told over many years that consistency in a code base is a virtue.

But if you insist on consistency, you're never gonna actually make any progress in cleaning it up. And we have our own versions of the simple living magazines, right? We have these books and these blog posts. They show you a beautiful vision of a completely consistent, perfectly abstracted code base and it looks so lovely. But you can't live in a place like that.

Just like you can't live in the homes in these magazines, right? Or the homes that are staged to be sold. They're just as unlivable as a hoarded house and I'll show you why. Here is a picture of a living room that has been staged to sell in a house. And it looks really nice. Looks super cute actually. It's like a nice little,

got cardboard floors and everything. And what we're looking at right here is the front door. But there's a lot of things that aren't present here that you would need if you were actually gonna live here. So for example, where do you put your coat when you come in the front door? Where do you keep your handbag or your messenger bag or 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 nice couch when you're all muddy and wet. Speaking of which, that's not a full-size couch. And where do you put a drink when you're sitting on it? Here's another view of the same room. Sort of looking from the front door towards where we were standing before. Notice there's no television. Where does that go? What about the Xbox, PlayStation,

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

If you're into reading, maybe it's books. If you're into video games, maybe it's game boxes and controllers and strategy guides. If you're one of these outdoorsy folks, maybe it's bikes and helmets and a kayak and muddy shoes. The things that you use need to be accessible, near at hand, findable at the very least. You need to tolerate some mess, not too much.

In code, we have these simple living magazines that show us unrealistically clean code. They set the wrong goals. Code that follows all the rules and is perfectly consistent and abstracted is unattainable. And even if you could attain it, you couldn't live with it. Like this bedroom, which 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, which is a trick to make the room look bigger. And those window coverings are light and airy and beautiful but will not keep anyone from seeing in. And the third fact is to inline.

I said that three times because I felt like it was important. Meaning, don't make refactoring something a separate chore. You need to do it as part of the stories, the cards, or the features that you're building. You need to clean up the code that you see rather than making it a separate thing.

It needs to be part of the everyday routine that you do. You need to incorporate it into your everyday routine. And I know I said there were three, but I have one bonus one, which is to deal thoughtfully with the exterior people, with the non-developers that you are interacting with. This is a difficult thing, right?

And I wanna say a couple things about this. First is don't ask for permission to refactor. Cleaning up and refactoring and doing those everyday things is part of your job. Asking for permission to refactor is like asking the homeowner's association whether you can vacuum your living room.

But be upfront, right? Don't lie to them about what you're doing. But don't ask permission. In that same vein, don't ask for forgiveness either. But learn from your mistakes. Part of your job is to learn how much is too much and how much is too little

and you'll go in both directions and learn something every time. Do ask everyone for advice. What do you think about changing this to go like that? What do you think about this? But don't always take the advice. And do work together, right? You have to live here.

This is the code base you live in. And I feel like this is important enough I gave you this on slide. You have to live here. 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 are 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. We need 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. Fred Brooks was right. We are not like other engineering disciplines. But if there is a silver bullet,

it lies in conceiving of software development as something entirely new. It lies in stepping outside of the framework that Brooks and Conway and everyone else has been viewing our job through for decades. I don't have all the answers, but I've spent the last two days here at Emmerconf feeling like everyone here already knows that we're different. You know that we're not quite architects.

You know that we're not quite engineers. You know that code bases are not quite like any other artifact humans have ever produced. And you know that our old ways of understanding and evaluating our work are no longer enough. And just that fact gives me immense hope for the future.

Thank you very much. It's been my privilege. Thank you.