 Today we're going to be talking about the metaphors we used for software architecture, how all of them are broken, and why set design is my favorite of these broken metaphors. Before I was a developer I worked in theater. I primarily designed and painted scenery, but a little bit of everything as long as it was backstage. Now usually when I talk about cross-applying my theater skills to tech, I talk about this one thing that kept happening. Let's say, completely hypothetically, that we're doing a play where we need to fly an actress in, maybe Heaven by George Walker. Now there's this character in Heaven, Judy, who is literally a black belt commando avenging angel. In one scene she descends from the sky, by which I mean the catwalks, to dispense some heavenly wrath. Let's say, again hypothetically, that the harness that's keeping her air in that first photo kind of looks like a cross between a diaper and a swing set. And that the entire production staff figures this out when it arrives in the mail, a week before opening. So now we have two opposed needs. On the one side our director, hypothetically named Kenyatta, is championing his artistic need to make Judy look awesome. On the other side our lead rigor Mike is championing his safety need to not kill Judy's actress, Michelle. Perhaps this dilemma reminds you of something closer to home. If we wanted to be reductive, we could frame the dilemma this way. We could call the director's objection to the swing set diaper thing, him risking Michelle's life unnecessarily. Then as technicians we would obviously be right and we could win the argument. And then reviewers would pan the show for looking ugly. Now don't get me wrong. This is a much better solution than an actress dying, which would in fact be catastrophic. But we can also aim a little bit higher than not catastrophic, can't we? Let's look at the situation a different way. Maybe we can have our costume designer work some trickery so that the swing set diaper gets disguised by Judy's camo outfit. Maybe we can keep a bright, bright spotlight on her torso so that you can keep the audience's eyes away from the harness. By approaching the issue in a spirit of collaborative problem-solving and negotiating to meet everyone's needs, we can have our cake and eat it too. We can have something that looks, okay, a bit less cool than the director had hoped, but still pretty cool. And we could do it in a way that doesn't risk safety at all. I use this experience a lot as an engineer. Then there's another big theater skill that I apply as a programmer, although honestly this one took me a bit longer to relearn. It's a skill that theater people call telling the story, and programmers call focus on business value. In 2006, I saw the forum theater production of Carol Churchill's The Striker, a somewhat dark play about ecological decay, postpartum depression, and the creepier parts of British folklore. One character is literally called raw head and bloody bones. In the script there are no spaces in between those words, I just added them for clarity. Now the theater this show was in is torn down now, gentrification happens. I couldn't find photos of it on the internet. It wouldn't have mattered much if I had. The set just was not that much to look at. Gray floor, gray columns, some debris scattered about. It didn't matter. There were things chittering in the rafters. There were creepily dressed actors crawling towards you, and then black out, so crawling towards you in the dark. I have seen a lot of plays by that director since. Kathleen Ackerly is the best director in DC, but I will never sit in the front row of one of her shows again. Nope, cannot make me. And that is how you know it worked. For The Striker to work as a play. The audience needs to believe that it's two human characters, Josie and Lily, are both very haunted and suffering from postpartum depression. If they're not convincingly human, that second bit, the depression, gets lost and the plot of the finale just does not make sense. So it's up to the rest of the production to convince us that fairies are real, so that Josie and Lily's actresses can focus on being humans. The set for The Striker wasn't impressive objectively, but it helped us tell the story. It gave the fairy actors lots of opportunity to peer creepily out from high places. It kept the action way too close to the stage for my personal comfort. In short, it made it easy to believe the things that Josie and Lily were seeing were real. This is a parable about the beauty of our code. What matters about our code is what it does. We talk a lot about business value, and sometimes, honestly, it just seems like a buzzword to me. It also doesn't really capture what a lot of nonprofits or open source projects are doing. So whenever I hear the phrase business value, I mentally substitute usefulness. Beautiful bulletproof, well-tested code is often more useful than the other kind. This is also rarely the most important thing about a project. The Striker set wasn't impressive on its face, but the play still gave me some nightmares. Similarly, I have written some pretty ugly code in the service of helping diabetics track their blood sugar better. I know which part of that sentence I care about most. These are good general lessons, but they're pretty general. I want to talk about software architecture specifically, not only about small line-by-line design decisions. Software architecture is controversial, and I think that's because of the metaphor we use for it. We visualize a building. We think, okay, the architect draws up the plans, then the builders execute. The architect has the creativity and a white-collar job. The builders have no creativity, and you can tell because they work with their hands. Another thing is this very hierarchical, classist piece of great man-theory nonsense. It caught on in the software industry because software has historically been quite susceptible to hierarchical, classist, great man-theory nonsense. Take the 10x developer meme. As many of you know, it comes from a book written in the 70s called The Mythical Man Month. It was by a guy named Frederick Brooks. In this book, Brooks misreads a narrowly targeted scientific paper to make a broad claim that some developers are innately 10 times as good as the rest of us. It gets worse. This is lesser known today, but Brooks goes on to recommend that engineering managers organize a surgical team around each of their 10x developers. Brooks does not mean surgical here in the sense of, oh, they have a strictly defined purpose, or that they execute very precisely. He means surgical in the sense of calling calipers to a nurse. That idea is what transmuted into how we think of software architects today. That is where we get this misguided notion that an architect should spec everything out and that a good architect will design something perfect for the entire life of a project that they will know based on a similarly perfect list of business requirements all of the classes that a project will need and the correct database and every microservice and every single detail of the APIs these microservices use to communicate with each other. That nonsense doesn't even reflect how buildings work in the real world. That nonsense does not reflect what actual building architects do with that fact. I come from DC, a city that is slowly turning each and every one of its warehouses and some of its theaters into condo complexes with a hipster bar on the first floor. Building architects are mostly not building beautiful, timeless art. They're taking a past architect's creative work and the ways it was embellished by its builders and the ways it was changed by the people who lived in it and they're trying to turn it into something new, something new that meets the needs people have now as opposed to the needs they had then. This sounds a lot like working in legacy code to me. Not glamorous, but useful. We've been talking a lot, a depressing amount really, about the impermanence of software this weekend or this week. Building architects and urban planners often have jobs where they're doing very little but repurposing the past. That's not quite what we're doing in software. Often we at least have the illusion of starting fresh. What if we want to aspire to more than turning the legacy code of today into the legacy code of tomorrow? When I got bumped into a software architectural, I had no idea what I was doing or what I was even supposed to be doing. Mostly I knew what I didn't want. I didn't want to specify wildly unrealistic waterfall nonsense that my implementing teams would then have to just ignore. I didn't want my code base to stratify into archaeological layers, each of them representing a different Rails fad and each completely unreadable once that fad passed. I didn't want to be any of the architects the building metaphor told me to be. I needed new metaphors. I wound up thinking a lot about set design, particularly this one show. Say y'all got it, y'all got it. My set design mentor, a woman named Elizabeth Jenkins McFadden, once designed a production of the Mary Widow for the Washington Savoy Arts. Watching what she did with it taught me a crucial lesson about set design, that it's about the ways that actors move through space. The Mary Widow is a comic opera. It's set in the high society of a tiny, made-up European country at the beginning of the 20th century. It's a culture where formal etiquette still dictates that people be announced when entering a room. And so the back of the stage was occupied by a long, high promenade for folks to enter on, with exactly one staircase for them to go down. You could see them walking for a long while before they made it to the staircase and joined the rest of the actors downstage. Except in a few scenes. In a few scenes, people would kind of sneak in from the wings in front of the promenade. Funnily enough, they were always the characters who were cheating on their spouses or plotting something. The set design created a visual language that said this character is being a sneaky, scheming jerk right now. Of course, that visual language would not have meant anything without the director and actors using it. Okay, you might be thinking, that's interesting, but what does it have to do with code? Let's look at a good old model view controller architecture. This is a set of boxes to put code in. We know, going into an MVC code base, that most or all of the code and its models have to do with the domain concepts and data that our application deals with, that most of the code and the views will have to do with displaying data to users, and that most of the code and the controllers will translate incoming user requests into stuff that the models and views need to do. This contextualizes our code. If I put these three lines of code into a person model, I am saying that a person's full name is an important part of how our code base understands a person. If I put these other three lines of code, identical to those first three, into a user's index view, then I am saying that a full name is not intrinsic to a person. I am saying it is only a formatting detail that matters when we've got a whole table of users to display. That's a low level design choice, but it's a low level design choice that only exists because of the architecture. In the merry widow, there wouldn't be a visual distinction between people who announce themselves like normal people and people who snuck in and didn't exist. But just as importantly, without actors to walk on it, the grand promenade would not be a way of separating sneaky people from upstanding ones. It would just be a very large and attractively painted balcony with a staircase hanging off it. A model view controller architecture doesn't mean anything until engineers start putting code into each of these boxes. The point of an architecture is to give other engineers meaningful choices so that those choices are in code that they write. And so maybe architecture is about giving people a lot of boxes. Since putting something in a model means something different than putting the same thing in a view, maybe it'll also mean something different if you put it in a form object or a service object. You can add a lot of letters to MVC that way. But I did not like that definition of architecture. I had a really strong gut reaction to it. I did not like that definition of architecture. I did not like that definition of architecture, too, that are very alike. Maybe the architecture has a pattern called presenters for display only code that applies to all instances where a domain concept might be displayed. Another pattern called view objects for all the code that might underlie a given view template. Then I need to think about splitting that hair all the time on my team who has low-level issues with female engineers. That person is not going to be able to resist being super passive-aggressive about whatever decision I made there. All of a sudden, a lot of energy from everyone is being poured into this one decision. And I think, is this decision generating business value? Is this decision making my code more useful by making it easier to read? Is it making my code more useful to be worth the energy me and my teammates are spending on it? Sarah May has this awesome metaphor called livable code. Like a lot of architecture metaphors, she asks us to visualize a building. But this metaphor works a lot better than the other ones because she asks us to visualize a specific building, namely our own house. If we let clutter build up everywhere, then it's hard to use our houses at house. If the kitchen table, or if you can't get to the kitchen table and you've used the coffee table, is strewn with books and unsorted mail all the time, we have to eat on the couch. Stuff like that. It goes further. In Olivier Lacan's talk on errors on Wednesday, he talked about the intimidation factor of scary errors. There is always something in any given code base that is as scary as the closet of doom in your house that you do not open. People similarly avoid this area. They change the code that they write. They change the path that they take through your house to never have to deal with the unclear metaprogramming stack trace that vomits out at them if they open that closet. But the other half of livable code is that you can get too clean. If you have a really complicated organizational system or a super minimalist interior, if you have something that can't abide a stack of books you happen to be reading somewhere, you wind up spending more time catering to your house than living in it. I think there's even more to it than that. I think part of the problem with many box architectures is that they're ultimately the same as architectures where the architect names every single class in the application up front. To talk about that problem, I'm going to share another story for my theater days. The story of one of my more embarrassing mistakes. Stuart Little is a kid's play. It's based on the book of the same name by E.B. White. It's about a human family in New York that adopts a mouse as a kid. It's also the first show I ever did a full design for instead of just designing bits and pieces. I really wanted to impress my director. So I tried to take all of the many ideas about distorted perspective and scale, about playfulness and historical context and nostalgia that we had talked about in the first design meeting, and I put them all into my design. It was a mess. I mean, these are pretty drawings. But as a theatrical design, it had too many elements. There was this really cool idea I had about putting door frames in these moving skyscrapers, but there just wasn't time to build it. And that one really cool idea was buried in all of the rest of the things that were going on in the design. My director, Michael Bobbet, was really nice about it, but it was clear that I'd need to change a lot of stuff. So that we could figure out how to cut things and stay true to the core of it. Michael said something that stuck with me for a really long time. Betsy, Michael said, you're trying to tell the entire story with your set. You do not need to do that. You have to leave something for the actors to do. It wasn't just that I didn't need to do everything with my set. It wasn't just that because I tried to do everything with my set, I wound up succeeding at nothing. It was that a good set didn't try to do everything. It would only try to do enough to support the actors, as they told the story. It would trust the actors to do a good job with that and focus on its job instead. So I took that feedback and I pulled back a lot. We wound up building a set that had the things I cared most about from my original design. Like skyscrapers, so much taller than the kids in our audience that they would think that, sure, maybe mice and kids could be about the same size. It turned out pretty good, I think, especially given our budget. And so this is a really happy story in the end, actually. Great time to drink some water. It's a happy story that has helped me a lot as a software architect because it helps you remember every day that my designs not only can't but shouldn't try to do everything. If they do, and if that happens, I am insulting them. I am saying I don't trust them. I am saying I don't respect their intuitions, their analytical abilities, their creativity, their domain knowledge, their subject matter expertise, their 3 million and 5 really hard and crucial skills that go into making an effective software engineer. When I specify everything, I am not enabling meaningful choices because I am not enabling choices at all. When I give people too many boxes, I am not leaving them room for judgment calls. I am not leaving them meaningful choices because none of the choices mean anything. I am doing all of the horrible 10x developer surgical team nonsense I was decrying earlier. So maybe we should just have no architecture and no architect and let the team figure everything out organically. One of my favorite shows to work on didn't even have a set, just a chair. It was so minimalist, the characters did not even have names. They were just called this one and that one. The actors were both named Jason. It was called In On It and I ran the sound board and I swear to God, I cried every single night. There was no set to constrain where the actors went and didn't go. It was, if you were, the plain rack app of theater. But they kept on returning to the same three positions anyway. There were points where they were elsewhere. The bit that made me cry, they were sitting against the back wall of the theater. But they kept on returning to these same three positions. The one where their relationship was falling apart and they were yelling at each other about petty things like taste and music or dishes in a sink. The one where they were facing the audience together, playing baseball or dancing or otherwise happy. And the one where they were having discussions about the spoiler that made me cry every night. It turns out that everything in structure or it doesn't make sense. If a set design or an architect isn't providing that structure then something else needs to. The reason architects are useful is not because we have special skills or knowledge. The reason architects are useful is that our primary responsibility is to the macro structure and this frees engineers up to think about future details. Maintaining an architect is not the only way to protect that macro structure and keep everyone pointed in the same direction. If you're careful and intentional and take your time, team consensus can get there too. It's just easier to fool yourself then because you're focused on both the macro and the micro at once. Hard to tell the difference between them. Whether your team designates an architect or relies on consensus, maintaining the architecture is a collective responsibility. At this level, meaningful design choices is contextualized by the architecture, but each of them can change it too. If you put enough of your business logic in your controllers, then guess what? Service objects are not your business logic box. Your controllers are. I don't care what your architect or your diagram says. People's understanding of what goes where is the real architecture and it is much harder to change than the documentation or the code. And again, this means that all of this is all of our responsibility, whether we call ourselves architects or not. Heavy stuff because we've gone over all the ways to get it wrong. If too much architecture is stifling and too little is confusing, then how do we Goldilocks our way out? Maybe we're still looking at this the wrong way. Maybe the idea that there is a correct set of three or six or 12 patterns to pick for any given code base, a given hierarchy of classes to define, a given anything is the thing that doesn't work. Maybe we need to look at process rather than product. We're looking at the structures in our heads, after all, not the structures in our code. Most of the work on a set design is usually completed before the play goes into rehearsal. It has to be pretty waterfall that way. Since the set design helps the director define the visual language they use to position the actors, it kind of has to be ready when the actors are. But it's not all waterfall. There are countervailing things. Throughout the rehearsal process, the stage manager is sending out rehearsal reports every night. These summarize any information that the director and actors learned about the show's technical requirements during that rehearsal. If they realize that the pay phone needed to be upstage left in order to make this transition work, then they can let the set designer know that, yep, that's where it needs to be. And the set designer and director have an opportunity to have a conversation about that. The actors through technical rehearsals have all of the designers there, along with the actors, along with the orchestra if you've got one, along with everyone. They're an opportunity for the designers to observe how elements work in the actual context of the actual play. Sometimes there's a lot of opportunities for the set designer to change things. There have totally been times when I have gone up on stage during a pause, moved some scenery around and called out to the director, but the set is often already built, so sometimes there are as many. Not always already built, let's be real. There's always some little tweaks to be made, though. Sometimes all you can do is adjust a paint color to look better under light, but you can always at least do that. The reason the traditional building metaphor for architecture is broken is that it's about waterfall and hierarchy. It's about a 10x person directing a team of individual cogs to follow a plan exactly. The way to escape it is therefore to be agile. It's to constantly talk to each other. It's to have implementing developers talk back to their architect or talk to each other and say, hey, this isn't working. How can we make it work better? Two, totally hypothetically, tell your architect for two weeks that the service would really be more stable and go. Luckily, this totally hypothetical architect did wise up and listen. There seems to be a lot of anxiety about the future of Ruby lately. It seems like we're saying this isn't working a lot and wondering whether features from other languages, like static typing and immutability, would lock down Ruby's weirder edges and make Ruby work better. The reason that this is not a tangent is the same as why I think that this is totally the wrong direction. Let's take monkey patching. Now, I have definitely looked at monkey patches a lot and said, this isn't working. But more and more, I still find they symbolize the things I love most about Ruby. So this framework class doesn't do what you want it to. Well, fine. Just open it back up, override that method and carry on. Do you want to rewrite random number generation to enable really cool musical effects ? Go ahead. Do you want to have your own special version of file utils like Bundle will need to after Gemified's standard libraries hit this Christmas? Well, Bundle's maintainer doesn't really think this is fine, but at least he can write it. Monkey patching can create more problems than it solves, but it's also a promise that no matter what the problem, there will be some way to solve some of the problems in Ruby. We have a lot of decisions when he built Ruby, but he had the humility to recognize that his decisions wouldn't work for everyone, and so he also gave us the power to change them. Sometimes our decisions are going to be stupid, but you can't empower people to do cool creative mold breaking stuff without also empowering them to make mistakes. And that's what we do in architecture. In these macro level decisions, not just line by line ones, it lets everyone participate. It lets everyone share the responsibility. That's the positive way of looking at monkey patching, I think. That we get to make meaningful architecture choices all the time. Whether we designate an architect or not, we're all collectively responsible for this architecture. Whether you're a capital A architect or not, needs to be about empowering people. It needs to be about giving them the tools to build their thing. To focus on what they find useful. To tell their story. So yeah, I'm Betsy. I just founded a software consultancy called Cohere. If you'd like my perspective on architecture and would like me or my co-founders this can happen. You can also subscribe to our newsletter at tinyletter.com slash Cohere. I forgot to put this on the slide, but if you want more of my feelings on architecture, then I am guest-starring in a course that Abdi Grimm is putting out starting in early December and you can sign up for that. You can find me personally on the internets at Betsy the Muffin on Twitter. Now, since I assume you are all ready to follow me right now, I'll give you a fun fact. The bubble-wrapped couch in my cover photo is from my favorite of my set designs. For Priscilla dreams the answer. In this photo, Priscilla explains to a boy she is dating just why her couch is covered in bubble wrap, although I'm afraid that won't illuminate much for you. You see the aliens who believe she will save the world want to make her apartment as low risk of place as possible. As an experienced software developer, I make more in an hour than I did most days as a theater professional. I have made more in a day than I made in an entire ten-week theater internship. Sure, we're not all rich, but on average, we do okay. The recession of 08 never really left America. And internet-based entertainment is cheap and omnipresent nowadays. So people are going out and spending 25 bucks at a theater ticket a lot less often. It is killing the industry. A lot of theater professionals aren't doing so hot right now, including, crucially, some of the people I mentioned as mentors in this talk, including to go back to legacy, some of the people whose legacy I am. So if you have that 25 bucks and you want to spend it on a theater ticket, know that you will be doing at least three things. You will be paying someone's grocery bill for a week. You will be providing jobs in your downtown that aren't at hipster bars. And you will be turning off Twitter for at least 90 straight minutes. I can promise you those three things and you may even enjoy the show. All right, now I'm actually done. Thank you.