Set Design: Putting the "Art" in "Architecture"
Haibel, Betsy
I thought of software architects as petty waterfall dictators. Then I became one. My theater background saved me. In this talk, we’ll look at set design — an ongoing, collaborative process — as a model for a more agile kind of “architecture” than building metaphors allow us. You’ll learn about the most important part of any architecture (hint: people), about using architecture to foster team creativity, and about the agile-architecture superpowers that Ruby gives us. No matter your title, you too can architect!
 Good morning. Today we're going to be talking about the metaphors we use 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 I did 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 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 appear 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. It's also rarely the most important thing about a project. The Striker's 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. Now, 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. The entire 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. 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 callipers 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 D.C., 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 are 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. They are 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 are 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 architect, 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 archeological 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. See, you 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 of reformal 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 are all of the code in its models will have to do with the domain concepts and data that our application deals with. That most of the code in the views will have to do with displaying data to users. And that most of the code in 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, which are practically 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 is only a formatting detail that matters when we have a whole table of users display. That is a low level design choice. But it is 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 like jerks if the grand promenade 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 can silently annotate all of the implementation code that they write. 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 will 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. In part, I have this reflex of assumption that if an architecture has 12 patterns in it, there's going to be two 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 of the code that might underlie a given view template. Then I need to think about splitting that hair all the time when I'm trying to code. I need to think about that very fine distinction a lot. And I need to potentially defend that decision in code review. And frankly, if there's anyone 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 enough, 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 asked us to visualize a building. But this metaphor works a lot better than the other ones because she asked us to visualize a specific building, namely our own house. If we let clutter build up everywhere, then it's hard to use our house as a house. If the kitchen table, or if you can't get to the kitchen table because you've just moved 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 Bobbitt, was really nice about it, but it was clear that I'd need to change a lot of stuff. We started talking about what I'd been trying to do with my design 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 had 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. So I thought maybe my kids could be about the same size. It turned out pretty good, I think, especially given our budget. 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, I am not leaving anything for the implementing developers to 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 out 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. Sure, 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 very emotional 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. Designing 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. Each of our low 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. 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 there is a correct set of three or six or 12 patterns to pick from a 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 final set of rehearsals, play goes 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, hey, I think this looks better. How do you feel? 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. This framework class doesn't do what you want it to. 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 like Sonic Pi does? 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? 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 fix it. Matt's made some architectural 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 because Ruby lets us make our own mistakes and build our own things, it empowers us all to participate 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 the architecture of our systems. And 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 right there to apply it to your code base, this can happen. You can also subscribe to our newsletter at tinyletter.com. 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 Obvi Grimm is putting out starting in early December, and you can sign up for that. You can find me personally on the Internet at Betsy the Muffin on Twitter. Now, since I assume you are all going 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 place as possible. One last note. 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 10 week theater internship. Sure, we're not all rich, but on average we do okay. The recession of O8 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.
 Good morning. Today we're going to be talking about the metaphors we use 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 I did 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 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 appear 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.  It's also rarely the most important thing about a project. The Striker's 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. Now, 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.  The entire 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. 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 callipers 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 D.C., 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  are 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. They are 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  are 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 architect, 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 archeological 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. See, you 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 of reformal 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  are all of the code in its models will have to do with the domain concepts and data that  our application deals with. That most of the code in the views will have to do with displaying  data to users. And that most of the code in 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, which are practically 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  is only a formatting detail that matters when we have a whole table of users display. That  is a low level design choice. But it is 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 like jerks if the  grand promenade 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 can silently annotate all of the implementation  code that they write. 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 will 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. In part, I have this reflex  of assumption that if an architecture has 12 patterns in it, there's going to be two  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 of the code that might underlie a given view template.  Then I need to think about splitting that hair all the time when I'm trying to code.  I need to think about that very fine distinction a lot. And I need to potentially defend that  decision in code review. And frankly, if there's anyone 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 enough, 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 asked us to visualize a building. But this metaphor works a lot better than  the other ones because she asked us to visualize a specific building, namely our own house.  If we let clutter build up everywhere, then it's hard to use our house as a house. If  the kitchen table, or if you can't get to the kitchen table because you've just moved  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 Bobbitt, was really nice about it, but it was clear that I'd need to change a  lot of stuff. We started talking about what I'd been trying to do with my design 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 had 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. So I  thought maybe my kids could be about the same size. It turned out pretty good, I think,  especially given our budget. 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, I am not leaving anything for the implementing developers to  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 out 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. Sure, 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 very emotional  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. Designing 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. Each of our low 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. 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 there is a correct set of three or six or 12 patterns to pick from a 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 final set of rehearsals, play goes 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, hey, I think  this looks better. How do you feel? 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. This framework  class doesn't do what you want it to. 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  like Sonic Pi does? 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? 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 fix it. Matt's made some architectural 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 because Ruby lets us make our own mistakes  and build our own things, it empowers us all to participate 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 the architecture of our systems.  And 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 right there to apply it to your code base, this can happen. You  can also subscribe to our newsletter at tinyletter.com. 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  Obvi Grimm is putting out starting in early December, and you can sign up for that. You  can find me personally on the Internet at Betsy the Muffin on Twitter. Now, since I  assume you are all going 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 place as possible. One last note. 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 10 week theater internship. Sure, we're not all rich, but  on average we do okay. The recession of O8 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.
Set_Design_0_47.png Set_Design_48_131.png Set_Design_132_287.png Set_Design_288_1007.png Set_Design_1008_1631.png Set_Design_1632_2183.png Set_Design_2184_3659.png Set_Design_3660_4139.png Set_Design_4140_5171.png Set_Design_5172_6491.png Set_Design_6492_6671.png Set_Design_6672_6839.png Set_Design_6840_6923.png Set_Design_6924_7043.png Set_Design_7044_8519.png Set_Design_8520_10175.png Set_Design_10176_10331.png Set_Design_10332_10811.png Set_Design_10812_12263.png Set_Design_12264_15263.png Set_Design_15264_15995.png Set_Design_15996_16535.png Set_Design_16536_17219.png Set_Design_17220_18575.png Set_Design_18576_19247.png Set_Design_19248_20003.png Set_Design_20004_20795.png Set_Design_20796_21251.png Set_Design_21252_21815.png Set_Design_21816_23051.png Set_Design_23052_23963.png Set_Design_23964_25427.png Set_Design_25428_26459.png Set_Design_26460_27035.png Set_Design_27036_27899.png Set_Design_27900_28727.png Set_Design_28728_29363.png Set_Design_29364_30215.png Set_Design_30216_30587.png Set_Design_30588_31703.png Set_Design_31704_31919.png Set_Design_31920_32759.png Set_Design_32760_33707.png Set_Design_33708_35831.png Set_Design_35832_36359.png Set_Design_36360_37211.png Set_Design_37212_39695.png Set_Design_39696_40775.png Set_Design_40776_43163.png Set_Design_43164_44459.png Set_Design_44460_45035.png Set_Design_45036_45131.png Set_Design_45132_46415.png Set_Design_46416_49247.png Set_Design_49248_49403.png Set_Design_49404_49440.png
Good morning. Today we're going to be talking about the metaphors we use 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 I did 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 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 appear 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. It's also rarely the most important thing about a project. The Striker's 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. Now, 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. The entire 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. 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 callipers 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 D.C., 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 are 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. They are 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 are 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 architect, 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 archeological 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. See, you 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 of reformal 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 are all of the code in its models will have to do with the domain concepts and data that our application deals with. That most of the code in the views will have to do with displaying data to users. And that most of the code in 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, which are practically 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 is only a formatting detail that matters when we have a whole table of users display. That is a low level design choice. But it is 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 like jerks if the grand promenade 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 can silently annotate all of the implementation code that they write. 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 will 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. In part, I have this reflex of assumption that if an architecture has 12 patterns in it, there's going to be two 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 of the code that might underlie a given view template. Then I need to think about splitting that hair all the time when I'm trying to code. I need to think about that very fine distinction a lot. And I need to potentially defend that decision in code review. And frankly, if there's anyone 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 enough, 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 asked us to visualize a building. But this metaphor works a lot better than the other ones because she asked us to visualize a specific building, namely our own house. If we let clutter build up everywhere, then it's hard to use our house as a house. If the kitchen table, or if you can't get to the kitchen table because you've just moved 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 Bobbitt, was really nice about it, but it was clear that I'd need to change a lot of stuff. We started talking about what I'd been trying to do with my design 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 had 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. So I thought maybe my kids could be about the same size. It turned out pretty good, I think, especially given our budget. 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, I am not leaving anything for the implementing developers to 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 out 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. Sure, 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 very emotional 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. Designing 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. Each of our low 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. 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 there is a correct set of three or six or 12 patterns to pick from a 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 final set of rehearsals, play goes 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, hey, I think this looks better. How do you feel? 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. This framework class doesn't do what you want it to. 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 like Sonic Pi does? 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? 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 fix it. Matt's made some architectural 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 because Ruby lets us make our own mistakes and build our own things, it empowers us all to participate 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 the architecture of our systems. And 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 right there to apply it to your code base, this can happen. You can also subscribe to our newsletter at tinyletter.com. 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 Obvi Grimm is putting out starting in early December, and you can sign up for that. You can find me personally on the Internet at Betsy the Muffin on Twitter. Now, since I assume you are all going 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 place as possible. One last note. 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 10 week theater internship. Sure, we're not all rich, but on average we do okay. The recession of O8 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.
about the metaphors we use for software tech, I talk about this one thing that kept most important thing about a project. The have no creativity, and you can tell because they got it. My set design mentor, a woman named In a few scenes, people would kind of sneak in that a person's full name is an important part of helped me a lot as a software architect because and intentional and take your time, team Maybe we need to look at process rather than traditional building metaphor for architecture is theater professional. I have made more in a day