Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode 14 of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the many and varied aspects of job satisfaction.

[00:00:15] Dave Adsit: I'm Dave Adsit, a CTO, and I have been thinking a lot about the physics of cutting down trees.

[00:00:21] Matt Baker: Matt Baker, software architect. Lately, I've been thinking about function as a service.

[00:00:26] Allan Stewart: Today's episode topic is software architecture. Software architecture is one of those things that in the industry, we have a general understanding that it's pretty important, but sometimes it's quite nebulous. What even is architecture?

[00:00:41] Dave Adsit: Why does it matter? Well, architecture is indeed nebulous. I've heard it described in a lot of ways. One of them is, is Martin Fowler has said architecture is the important stuff, whatever that is. I've heard people call it the hard stuff, whatever that is. I've heard people say architecture are the decisions that matter, no matter where they are in the stack.

[00:01:06] Matt Baker: I've heard a similar thing. Architecture is the things that are hard to change. I've heard one person distill it down to the word interfaces. I thought that one was pretty interesting. I also like to treat it as a hindsight term. So, like, once you're done building the thing and you've got customers, whatever you have, that's your software architecture. So it's kind of an emergent property. A few others for me, I think at times this is, like, the term that's so overloaded or often overrated, and it can get to the point where it means just about nothing, depending on the context. Lastly, I think sometimes while trying to be a good architect, whatever that means, people will build incredibly complex systems that are designed, quote-unquote, designed right based on industry standards. I think maybe, like, an easy example of this is, are people that go into a shop that needs a little, like, shopping cart and they end up shipping them, like, 40 microservices because because that's how they were supposed to do it. So I think at times, like someone trying to software architect in a way that they've read about or watched it to ox, like, you know, at conferences and whatnot, that can lead to unnecessary complexity.

[00:02:21] Dave Adsit: I think if I'm going to be the least charitable, software architecture is the stuff done by the people in the ivory tower that we later ignore. Or if I'm going to be the most charitable, software architecture is a reaction to the places we've been burned in the past. Maybe that's not the most charitable, but maybe that's just an acknowledgement of the humanity of the people writing software.

[00:02:49] Matt Baker: It's interesting because I believe that everything we've just said, all these different angles on architecture are probably all, not probably, I think they're all correct. And there's a big contextual component of this that probably determines what's most correct for your given situation. But I think what we've successfully demonstrated from the outset is that this term is overloaded and means different things to different people at different times.

[00:03:15] Allan Stewart: And just that there's so many different kinds of systems and there's so many different goals that people are working towards. In a business, software architecture may be about how do we deliver functionality and make money with a reduced spend? And for an open source project, then architecture might be, how can we allow a lot of contributors to work in this stack? How can we expand the use of this free software that we're giving out or potentially build a business on the side of it? There's a number of things there, but I think a lot of these definitions about different decisions or what's important. Yes, it is contextual, but at its heart, it's this idea of, can you make software do what you want it to do in a reasonable amount of

[00:04:06] Matt Baker: complexity? Yeah, I think it's as a business or project starts to grow, almost always that brings change for the business or the project, which a lot of times means changes for the software involved. And one of the ways I think about software architecture is the thing that keeps those two glued together to being like the project or the business or whatever you're writing the software for and then the software, right? Because there's nothing intrinsic in any of that that's going to say this software will continue to reflect the important needs of this project, this business, whatever. And when they're both changing, you face the risk of drift, right? The software can get disconnected from what it was built for. And then you start trying to shoe horn it in and it just gets a little bit awkward over time. So another way you could look at software architecture is the agent that keeps the software close to the needs of the business or project or whatever, so it can best support.

[00:05:02] Dave Adsit: I like that. Since you said it, it's been like kicking in my head, Matt. I really like the idea that software architecture is only known in retrospect when we see what parts of the system ended up being important. Maybe that's not even what you said, but that is what I heard.

[00:05:22] Matt Baker: No, that's it.

[00:05:23] Dave Adsit: We know what the architecture is because we know what ended up mattering. And maybe what ended up mattering was that one for loop inside inside the TCP connection handler. And maybe what mattered was the interfaces between microservices that the different teams all agreed to.

[00:05:47] Matt Baker: So, question, Dave, when you say mattered, like there's a value statement in there, right? Like, these things are more important than these things. From what lens do you find that you can most effectively make that consideration? Like, how do you say, like, "this part of the system matter and this part didn't," like, what, What drives that value judgment?

[00:06:05] Dave Adsit: I think that it's the stuff where it either cost the company a bunch of money or a bunch of time or saved the company a bunch of money or a bunch of time. I was listening to a business podcast recently, and I learned that at Facebook, because they're operating at such a huge scale, they make a jacket for people who save Facebook a billion billion because that's possible at that scale. Also, thanks for the billion dollars. Here's your hundred dollar jacket. Seems like, once again, the industry not valuing engineering for what it is, but let's set that one aside. But it's the stuff where you end up finding the critical bug that was such a huge problem for so long, or you do an analysis and you find that that function gets it's called hundreds of thousands of times and always performs well. I think those are the things that matter. I think at the end of the day, it kind of comes back to what does it mean for the business? Does it mean the software performs well enough to close the deal or the software performs poorly enough that it prevented the deal?

[00:07:16] Matt Baker: I think the perspective in either one of those scenarios, there's this element of, like, well, what did it do for the company? I actually had a strategist call me out on this the other day. I'm going to call you out on it, Dave. The business, business, that term, not picking on you, Dave, I do the same thing. I've just said it in this call, but he stopped me when I said the business, and he kind of laughed and said, "why do you do that? Why do you separate your work from quote unquote, the business when, when obviously you're the same thing," and what is it's driving this point for me, how you determine a successful architecture, what parts of your architecture mattered. I think almost always comes back to what, well, what did you do for the thing? That's making us money. Did you really hurt it? Was it a detriment? Like you pointed out, or did you make us a ton of money or did you enable us to to pivot quickly, I don't know, integrate an acquisition quickly, whatever. But what I don't think it ever is for me is technical achievements on their own. So I would call foul if someone said like, "your great architecture is, like, this great data pipeline thing that allows you to move data around the system and this clip, and you can do all these fancy things with it." And it might look good on paper, and it sure as hell might get you a job somewhere else because it looks good on your resume, but, like, if it didn't do something for the business, you know, it didn't matter.

[00:08:26] Dave Adsit: Yeah, I completely agree with that.

[00:08:27] Matt Baker: And there, I just said it again, the business.

[00:08:31] Dave Adsit: Well, so I think that we have to be careful there because sometimes we say the business as other, and sometimes we say the business as inclusive of us. And I hear it more often from senior your technical people as being inclusive. And when we exclude the tech people from the concept of business, we do so to the detriment of both technology and the business as a whole.

[00:09:01] Allan Stewart: It swings both ways, right?

[00:09:03] Dave Adsit: Yeah. I think that it's super important for the architect to be be someone who is considering that bridge between technology and business value. I've seen a lot of architects who don't consider that. They only consider their own personal value, which means to me that they're not acting as an architect. They're acting as, I don't know, some kind of potentially very skilled engineer, but not with a lens toward achieving something as a company or as an organization.

[00:09:39] Allan Stewart: I like that concept. If we're using the business or any other term, you know, marketing or sales, and we're doing it in the sense of othering, then I think that we're in danger. But if we're using it in the sense of we're trying to unify ourselves and understand that this is something that is useful for the entire company and for the purpose of the company rather than any individual or subsection of that company, then I think that makes a lot of sense to me. I think you're on the right track when you're using it in that inclusive way.

[00:10:15] Dave Adsit: It's a good reminder that when you are doing a craft, you are doing it for that purpose. Software as a craft is about being a business-oriented person. It doesn't necessarily mean that you're going to go out and do sales, though at some point, if you're in a small enough startup, you may be asked to. But it does mean that you are doing this not to create the best art or to pursue your own ends. You're pursuing a common end for an organization.

[00:10:45] Allan Stewart: We're establishing here that architecture has a lot of variety to it. I think about, why do we even call it architecture in the first place? It comes from building and like structural architecture. And the physical building analogy is tired. It's an old model that doesn't hold up very well. Just like all models, it does at least have some value to it. It can be useful for us to think about. In physical architecture, there's a lot of decisions that are made. There is an aesthetic aspect to it, right? We don't all just make the same square buildings with exactly the same rooms because it has to fill a function. And one of the functions is be pleasing for people. But then there's also other functions that we have to consider. It would be great if it could just be completely, somebody might want a completely open office space. Well, why do you have to have these pillars? Well, you've got to hold up the building somehow. Why does a load-bearing wall have to be there? Why do you have to have plumbing in a certain way? How do you have to do your HVAC? It's going to depend, and it could radically change how you build your building. Likewise, with software architecture, there are decisions that we have to make that determine the success, right? Is this thing that we're building built for purpose? Is it actually going to accomplish the goal that we set out for it? That to me is what software architecture is all about.

[00:12:06] Dave Adsit: I think for a long time in our industry, architecture has been a thing that people aspire to as a recognition or an acknowledgement that you've gotten there, you've done it, you are the smartest engineer in the room. And I think that if we look at architecture as at the purpose of architecture, it calls into question some of those ideas.

[00:12:31] Matt Baker: Yeah. Yeah, I kind of like it because so, like, I agree, it's an aspiration for a lot of engineers years to become an architect for any number of reasons, I think. But what I've also experienced in this role is, every time you get into this role, it's never had the impact that I've wanted it to. I struggled to understand that for a while. I got some clarity on it, trying to found and build a startup. And the clarity I got from that experience was, I really enjoy using my technical skills to to push the, I was going to say, the business. I really enjoy using my technical skills to grow the company, to help it grow, to get deals. And I don't mean just by coding. I'll get on a call. I'll do cold calls with you. I'll call technical customers and talk tech with them. I'll go on site. I'll do whatever I can do, technical skills or otherwise, to help grow the company. And I get get a lot of satisfaction out of that. And it's helped me understand, maybe in part, why this role has always come up a little bit short for me. I've had it more than five times, less than 10 times at different companies of different sizes and with different goals in those companies. But the one common thing throughout was, I didn't feel effective. And surely a lot of that onus is on me, if not all of it. But regardless of that, what I do know is that I felt disconnected from from the company. I didn't feel like I could impact the company. Like, when you get into a software architecture role and you spend your time writing code style guides or implementation checklists or team health stuff, it's not satisfying for me. Like, I want to be solving a hard problem that yields fruit that I can see. And in this context, that always, almost always means solving a problem for the company that either, like, going back to what Dave said, makes them a lot of of money or saves them a lot of money or positions them to do one of those things. I don't know, this role is interesting for me. And I'm thinking back to the first time I stepped into a software architecture role. I was under the impression that it was all about code enforcement standards, going around and making sure everyone's shipping the right way. And they're doing TDD and they're writing this correctly and they're using the correct front end framework. And having been in And now what I would say is it's almost none of those things. Like a smart architect in my mind says, "okay, all that stuff, give it to the engineers, let them decide. Here are the few things that matter for this company. And here's the Venn diagram overlap, if you will, with our technical posture. I'm going to play there. I'm going to make sure that the work that you're paying all these expensive engineers to do is right on point for what the company needs. And to do that, I'm going to need to step out of this purely technical top of the ladder rung role into an adjacent space. I'm going to have to go talk with salespeople. I might go out on sales calls. I might go sit with support. I might go sit with product marketing." And that's, for me, a mark of, if we can pin this down, this term software architecture or software architect, a mark of a good one for me is someone who understands that yes, they have all that technical prowess, but it's really not the time to flex it in that way. You're not there to tell other engineers how to code now. And like I said, I think the smart architect steps back, says, "all right, you engineers got it. I'll tell you if I think you're driving us off a cliff, but short of that, I want to intervene. I'm going to go talk to sales and figure out what we need to build."

[00:16:00] Allan Stewart: I like that. I mean, the technical knowledge for a purpose. And I think it is okay to aspire to an architectural role. I think that there can be some real big value that comes out of it, Matt. But to your point, it's going to depend on what it is you have envisioned that you're accomplishing in that role. If you're aspiring to be the one in the ivory tower who hands down instructions for the unwashed masses to build these Egyptian pyramid-like structures where the more people you have working for you, the better. Maybe that's not so good. Maybe that's not the best way to deliver business impact.

[00:16:42] Dave Adsit: I mean, I know that I spent a lot of years getting really good at writing code and tests and delivering product to production so that I could finally graduate to a role where I didn't do any of that and instead made PowerPoints and Visios and Miros and went to meetings. Isn't that the dream of every engineer? I know that all the engineers on my team talk all the time about how they can't get enough meetings on their calendar because meetings are where all the real work gets done.

[00:17:17] Allan Stewart: For me, it's that application. Just like you're saying, it's not that I want to go and do something different. It's what I want to apply my technical skill in a way that matters. Yeah. So for me, a good architect is going to bring business value, but also have that technical know-how. Can we get something working well? Can we apply systems thinking to understand how the technology is going to work with our people systems? Systems. Sometimes we'll talk about socio-technical systems. That's a big deal. Design and communication are a big deal if you want to be able to have an architecture that meets a purpose, because it's hard to hold a vision in your head of something that doesn't actually exist in the physical world. We draw lots of boxes and lines, and we have diagrams and code analysis tools that print print pictures for us of what this is, but it's very abstract. Being able to take those technical skills and use it to communicate with humans is insanely valuable.

[00:18:21] Matt Baker: I was reading various definitions of software architecture leading up to this podcast and software architects and a subset of it is enterprise software architecture. I'm sure there's a technical definition for the difference. I will say that that difference has never mattered to me. But that being said, enterprise architects, I think in their definition, call out what Allan just said, that they act as the bridge between technical capabilities and strategy for the company, what the company needs to go do. And they kind of doubled down by saying a good enterprise architect, quote-unquote, good, will be able to deliver plans that only need authorization from the execs. So, like, if you're an exec according to this article or this definition, a good enterprise architect would bring you a set of options for a choice that needs to be made, right? I, for whatever, whatever goal you're pursuing, the architect would say, "okay, well, here's, here's your five options, they're all vetted, here's your trade off. Here's your cost. Which one would you like to do?" And you go forward. So in that way, it's pretty on the nose to what you're saying, Allan, right? They act as that go-between.

[00:19:31] Allan Stewart: Yeah. Helping people understand what does this even mean? I love the concept that architects provide options. And then your architecture generally is about that. How are you giving the business options to succeed? Because they're not going to be able to figure it out.

[00:19:47] Dave Adsit: It's a way of leveraging your technical expertise developed over many years of doing technology to help build a successful business. Hopefully we all want to be part of a successful business. Building a good architecture, one that does enough but doesn't do too much, leaves real options open as market conditions change, whatever, allows people to maximize their productive value. All of these are key components of architecture. I really like what you said there, Matt, about laying out some options and the consequences. Here's the pros, here's the cons, here's the doors we open, here's the doors we close. We can't create a perfectly flexible architecture that allows every option. We have to make decisions in both business, company leaders have to make decisions about the direction of the company and the strategy of the company. And we need to reflect those decisions in our technical systems at whatever scale. And that, I think, is an architecture fit for purpose. When the architecture, as defined by the architect architecture team, meets the needs of the business now and next, you know, wherever the business is going. And it's going to have to change over time because every business that is successful changes over time.

[00:21:18] Allan Stewart: I think it's really interesting to think about architecture and the way it changes. You have your system at some point, we have this code, we have this website or app or whatever it is, and it can do these things. What next? Next. You could do nothing, which is also a decision because the world will continue to change. And there will be security vulnerabilities. There will be new technologies that come out. Maybe the stack that you're on gets completely obsolete. So you need to be able to change in some way or another. Where you are at any given point isn't actually all that interesting. What matters is where you're moving. How fast do things need to change? Some systems don't need to change. I mean, I think we hear sometimes about legacy COBOL systems, for example, or around the turn of the century, there's a lot to do about Y2K and what is this going to mean for all of these businesses that are built on these old technologies. In some ways, it's terrifying. How come some of these systems haven't been updated? But on the other hand, they're working just fine. They haven't been updated because they haven't had the need to change. Maybe some of them have needed to change and not been able to, but others have not had to change at the same rate. A good architecture is going to allow those things that don't change to settle in and get solid and be maintained because you don't want them to go completely obsolete. But if they don't have to change quickly, then don't do all the overhead that's required for things that change quickly. Save that for the things where you really need that business agility, where you need to be able to react to market forces or changes over time. And that's where you put in your effort to make things flexible or fast that need to be fast, that can change quickly.

[00:23:14] Dave Adsit: You've said something there that's really, really interesting to me. And I think that it's the idea that I used to have about software architecture is that as an architect, I had to predict every potential change or configuration or option or whatever. Think about everything I knew about our business, our customers, et cetera, and what are all the possible options and bake them in because we had really long delivery cycles in our systems. And now, as a technology leader, I think a lot more about how can I make it cheap to change? And that's going to mean leaving out a bunch of optionality. I'm not going to put configurations or options in the software when we design it and then build it. Instead, I'm going to keep the system clean and keep my delivery pipeline flowing and shift to production two or three times a day. And when the needs of our customers and our market and our business change, the team will react as necessary. And I feel like that means that the architect needs to focus a lot more on the socio side, the people side of the socio-technical system, and a lot less on being the best guesser about which things to put in the XML config file.

[00:24:33] Matt Baker: It's amazing to me, and it never ceases to be amazing to me, how often engineers fetishize generality and, like, configurability, reuse, yeah, reuse, yeah, it's so DRY. It shapes, you know, like, I just, as I was thinking about this podcast episode, I was thinking about some, like, anti-patterns of, I've seen architects adopt, and one that's so close to ubiquitous it's it's a little bit unnerving and super frustrating if you're dealing with it, is someone who's trying to build the system in order to build the system. And that touches on, for me, Dave, what you're talking about. Like, I'm going to build this system so well that then we can build our product on top of it, and it'll be so flexible and no matter what market conditions come, we're going to be able to pivot. And I get why they do it. I get it, I get it, I get it. It's also, like, totally wrong to me, and the reason it's totally wrong to me is a belief that a single-use purpose-built system is more configurable, more extendable, and more adjustable than a configurable system, if you know what I mean. If you set down to write some code for a problem and you only write the code that's necessary to solve that problem, that's going to be more adaptable to change than the huge system that you went and built that's super configurable and generalized. Because there's just too much weight in the second option. I don't mean to belabor this point, but this thing comes comes up for me so much. It's so painful to watch these big systems get built with generality in mind when really the actual answer was just write code for the purpose-built thing, exactly what you need to move on. And I think that's another mark of a good architect to me, someone that understands that you're playing this trade-off game all the time of cost of investment versus payoff. You're always looking at what's the best way to solve this problem for the company's goals. And the devil's in the details, the best. And that's a hard question. And it takes a very astute technical mind, I think, to be able to navigate those, especially as the company grows. And that, going back to what we were saying earlier, is a great way to take your technical skills and start flexing them in a new domain. But it's unsexy. I get it's sometimes unsatisfying to solve the problem quick and dirty. But oftentimes that's the right case. And you need this, going back to, like, do we need an architect? If you don't have an architect in title, You do need someone that understands your system and understands the goals of your company well enough to be able to make these calls.

[00:27:08] Allan Stewart: I believe that you can't not have architecture. If there's anybody who does something with your software, they write code or even are configuring low-code tools or something, they're participating in software architecture. Even the intern who's learning to write their first lines of code, they are an architect. Now, that might not be their title, but they are architecting something. They're doing some kind of software design, and you can't get away from that. Now, you might not have that title, and you may have good reasons to avoid that title. But in my estimation, everybody is participating in software architecture. It's just a question of at what scale. The people who we tend to call architects are often operating at a higher scale where they're working across multiple teams or across an entire business for that purpose, for the purpose of the company. How do we accomplish the company's goal?

[00:28:12] Matt Baker: So holding that train of thought, Allan, how would you field the question, "do we need architects?"

[00:28:17] Allan Stewart: I mean, I would say, yes, you need the role. I don't know that you need the title, and it's going to depend a lot on your situation. In a small startup, you might have silly titles. It won't matter. You're the grand poobah of keyboard whacking. I don't know. That to me is less interesting. It's important in as much as we need to be able to find ways to communicate the types of work that we are capable of doing. And we want to be valued in the market for the skill level that we're at. But let's face it, that whole model is kind of broken anyway. Anyway, it's impossible to tell the difference between a kid who just got out of college, who's really sharp, bright, works hard and delivers a ton of value to the business. And yeah, they just got out of college. So they're junior. But what about the person who's been in the same job for 10 years and they're just kind of phoning it in? They're not really participating, but they're senior because they've been around for a long time. So the whole model is kind of broken. There's no, there's just no way to communicate effectively what someone knows and how they're going to impact the knowledge work at some other company that has a completely different context

[00:29:33] Matt Baker: Yeah, I agree, and it's, it's a total loaded question, right? Because there's, like, it ignores the other variable there, which is, um, how much it's, uh, situational or how dependent on particular context it is. I've been asking myself this question over and over again the past week leading up to this topic. And if I answer the question specifically from the lens of how I've been deployed in the architect role, I don't know. Because I will tell you that it's always been a little lackluster. I've always felt a little bit like I could be doing better are given a different position. You know what I mean? And I'm not quite sure why, like, if you gave me a couple of beers and said, "Matt, what's, like, your unfiltered, super biased stance?" I'd say, like, "well, the execs just never valued my opinion." Right. And, like, that's a pretty sob story position. Right. Like, they just didn't listen to me. Like, had they just listened to me. And so, like, I don't think that's right. I think that's more like catharsis than answering it that way. But But there's probably an element of truth there where, like, just because the technical track observes this is, like, the top of the top of a particular technical track doesn't mean that anyone else agrees. Right. And when you get into this role, like maybe you'll have the respect and the reverence of other technical people in the org. Right. Like, engineers might come to you and say, "what do you think of this design?" But it's definitely, I've never experienced this role as, "okay, now you have a seat at the strategy table. Let's talk about where we're going to take the business. And, Matt, we're going to help. We're going to lean on you to help us understand what's technically feasible." Like, that's the ideal role for me. That's what I want the role to be in practice. It's never been that. And I don't know why, like, I could go through and cite a bunch of, like, I could point fingers, I'm sure, at a lot of different reasons, but it's, it's never been there. And I think it's a shame because I do think that it's a great way to leverage technical talent. Like, CTOs are awesome, but they're not always the best person to ask the most technical questions to. Not because they couldn't answer them, but they're just not doing it day to day. They're in a slightly different role. And I think that there's a chance for architects to augment what the CTO is doing, be a technical representative for the strategy. And I don't know. I don't know why it just never realizes. And maybe it does at other companies. I've never sat at one, but I've always felt that it's a missed opportunity for sure.

[00:32:03] Dave Adsit: So one of the things that I have thought for a long time is that the closer you get to the seat of power, the easier it's going to be to frame technology decisions in terms of company strategy, the goals and outcomes of the business that you work in. And what I found is that that doesn't matter so much as your desire to do it and you're struggling to do it well. It's a skill you have to develop. And I think it's a critical skill for anyone who is in or aspiring to an architect role or title. You have to be able to think in terms of, why does this business exist? How are we accelerating this business using technology? Is technology the right answer? For what we're trying to do. You know, I think I've quoted this before. Dan North has said, "if you don't do software, that's how you win at software." I think the same is true for a lot of things. Like, there's times when I have wanted to build the best event-driven microservices, multi-team system. But at the end of the day, maybe a monolith supported by a small team is going to solve the need better. And that is something that we have to either have intrinsically or mature into or develop as a skill. And that's thinking about technology as a solution enabler rather than as an end unto itself. I've gotten in trouble a couple of times when it comes to product management and discovery, because sometimes I feel like product managers slip into to discovery as an end rather than discovery as a means to the end, which is delivering a good product that meets the needs of customers. We do exactly the same thing in technology. We build technology as though it were the end. The reason the company formed is so that we could have these seven people over in this room write code. That's not why the company formed. Almost most in every case. The company formed to do something else, and you get to help by using special skills that other people don't have.

[00:34:22] Matt Baker: I've been talking the past few episodes about house stuff. I've been in the throes of fixing up a house and then selling it. It's now sold. I'm free and clear, closed and all that good stuff. Along the way though, I've been working with a real estate agent. And this particular lady is the same agent I've been using for a little while. And she's really good. There's an analogy here that I think is useful. So bear with me for a second. When I'm talking with her about real estate stuff, there's a pattern she follows. She almost never brings problems to me without solutions. So even if the problem happens like like three days prior to her bringing it to my attention, she won't bring it up until she's gone and done some work and said, "and here's the things you can do." And so it might look like, "Hey, this person now for wants to counter offer on this, uh, but, but, but, or, like, the bank is saying this, uh, here are your paths out." Right. And she'll give me the, she'll, she'll bring me a problem and say, "I just need you to make a decision. Then we'll talk about the merits of each decision, and then we'll go forward." What she'll never do is tell me what I should value. What she'll never do is come to me and say, "I think you should sell this house for X. Therefore, here's the solution. Or let's talk about the solution." She'll never cross over into Matt or into telling me, "I think your value should be this. I think you should be trying to sell it for more. I think you should be trying to look for a house with some amount of acreage." Like, she doesn't go there with me. She always stays in this place that just acknowledges the fact that she's a real estate professional and she's there to help guide me through this situation. But she's not like a Matt professional. She's not here to tell Matt exactly what he needs in his life to be fulfilled. Right. And I think there's an analogy there with software architects and, like, how to be a good architect and just recognizing the fact that, like, there's certain things that you don't extend to, like, but as an architect, considering the analogy I've just raised, imagine being a CEO and having the architect come to you and saying, "let me tell you about how you should play in this industry." CEOs are often very tied into, well, depending on the stage of the company, but they're often very tied into the industry, what's making money and how they're going to go make money. This is the nature of their job. So when you go in there and you start telling them, "I think you should change what you value in order to make money," that's going to go afoul pretty quick. And I think we do this all the time, myself personally. And so a good architect, I think, knows how to thread the line that my real estate agent knows how to thread. She knows how to come to me and say, "we've got this problem. I know your goal is to buy a house, or I know your goal, CEO, is to increase your ARR by 20 this year. Um, here's a problem that's in the way of that. Here's five solutions to that problem. Here's their trade-offs. Let's talk about them. You make the call, and I'll go do it." Like, I think that to me, given my, my experience where I'm at now, I think that's an architect that's at least a quote-unquote good architect, and it sucks because, like, it's acknowledging that you never cross into being seen as someone that's helping steer the business business, and, like it or not, I just don't think that that's something that this role is meant to do, but it is meant to understand what the business wants and then help them understand how you can best technically serve it.

[00:37:39] Dave Adsit: And I think that that is a way that we build that configurability that we used to try to put into code. Instead of building the ultimate framework that has 7,300 hundred toggles and you can flip them all on or off in any combination. And it's all you need is this gigantic XML file. And once you've got it, you're good. You can do anything because the system is so flexible. We have to be able to apply that flexibility to what can be done with technology to meet business needs at whatever stage we are at. One of the things about architecture is that you're thinking about a system from a lot of levels of abstraction at once, or multiple time frame, time horizons at once. You've got to be thinking about what is this function doing right now, but what is this function doing in context of this larger class and this module in this product across the ecosystem that we're building, and what is it doing in the zero to a six-month horizon, in the six to 12-month horizon? Will this be the thing that sinks the company if we don't refactor it by the time we hit this scale? And if I were to build for that scale now, would I sink the company because I over-engineered a thing that should have just been simple? I think that that is one of the key things about architecture, is trying to balance a lot of different levels of abstraction and a few different time horizons at once to create real true options for your business person. If you go in and say, "well, we've got two options. We could build this event-driven microservices on top of Kafka, and it's going to cost this much, and all your wildest dreams are going to come true. Or we could just build this piddly little thing in PHP with a monolith and three engineers, and sure, it will only work until we have 10,000 customers. Do you want to risk the business on only having a system that can scale to 10,000 customers?" If we try to frame the options as though there is a clear and obvious choice, that is an area where we as technologists get in trouble. First of all, there isn't just a clear and obvious choice always, or even often, but also it makes people who don't come up through through a technology path more skeptical of us as the expert with the secret knowledge who is trying to manipulate them, and that is think is an area where I hesitate to use the word resentment because I don't know what is going on in other people's heads, but I have felt as though that were a motivating factor in some decisions at some points in the past in my career.

[00:40:29] Allan Stewart: Yeah, ruler is always a little skeptical of the scribe. I will point out that, uh, we're talking a lot about business. I think that these apply equally as well to other kinds of projects, you know, when we're talking about open source software, for example. Software architecture doesn't go away just because you aren't in business. There's some kind of goal, and by and large, most people who are getting paid to write software are in some kind of business, and so So that's just naturally where the language goes.

[00:41:00] Matt Baker: I also want to indict leadership a little bit here, going back to the business thing. We've been highlighting the error in thinking that tech is a means unto itself or product is a means unto itself. That is to say, it's an error to think that if you build the most technically sound system, you've done a good job if you were building that for a company strategy, because the only thing that says whether or not you've done a good job is how well it enables that company strategy technically. We've also talked about the anti-pattern that architects fall into where they just, again, they value tech unto itself. And I think that sometimes it's because they're not experienced or they just haven't learned that lesson yet. I think other times it's due to a vacuum they exist in because leadership has not created clarity. So one of the things that can be very frustrating as an architect is when you're charged with this system and you actually don't know what it needs to do because you're not getting the clarity, and try as you might, you don't get it. So there's so many facets to this role, this title, how it's going to go at a company. If I were to take a new job as an architect, probably the only question, and I had one question to ask, let's say in the interview for the sake of conversation here, that question would be, "what am I responsible for?" And if I don't get a clear answer on that, I'm out, right? If it's not, if the answer is like, well, just make sure the system works well and make sure the engineers that, no, no, if you can't say something to me, like, "I need you to focus on this area of the business that brings in 10 million a year, and I need you to make it bring in 25 million." All right, then we'll talk, right? But that clarity is so often missed. And so I don't want to come off as saying, well, it's all leadership's fault. Surely not, but sometimes it is. And I think one of the times that's commonly the cause is leadership not taking the time to create clarity for any number of reasons. I don't know why that happens, but I'm sure everyone talking right now and people listening to this can empathize with how frustrating it is to be there saying, "I'm technical, here's my skills, I can do it," and just not being given any sort of direction or clarity as to what the company needs.

[00:43:14] Dave Adsit: I'm willing to go a little bit farther and say that it is always leadership's fault because leadership is responsible for setting direction and building the system. That means if my team fails, it's my fault. If my team fails at delivering what we need as a company, I have failed because I didn't set them up to win. There may be some unwinnable situations, but you still didn't win just because it was an

[00:43:43] Allan Stewart: unwinnable situation. And I think it's important to remember that everybody involved is human. They're all going to make mistakes. So architects are just as human. They're going to make some mistakes. Business leaders are going to fail to create clarity or fail to understand why this thing is important because they just don't have great visibility. And that might be a communication problem where the technical person didn't explain it well enough or didn't put it in business terms, but it's also the job of leadership to make sure that they understand the things that are impacting the business. And if there's a technical thing impacting the business, they got to figure out how to understand that too.

[00:44:23] Matt Baker: So now that I've indicted leadership a little bit in the plight of architecture and the architect role, if you will, I'm going to switch the focus back to the architect and ask the question, and maybe I'll just pose it to you too, Allan and Dave, how do do you know whether an architect is performing? How do you measure performance for an architect, or how do you measure the performance of the architecture role?

[00:44:46] Allan Stewart: That's a really hard question, partly because I've never felt like I had a satisfactory answer to how do you measure performance of anything or any human being, I guess I should say. We can look at certain characteristics of machinery, and we can say, hey, I can tell how well this is performing at a particular thing. But humans are so dynamic and they interact and they're expected to do things that we can't get machines to do. We look at a machine, it's like, oh, this printer is great. It can print this many lines, and it has this many DPI. This bit of silicon has this many transistors on it. Isn't that amazing? And we've boiled it down to just a number. Those things are machines that we've created for a purpose and humans are just outside of that. And we rely on humans to figure out all the other stuff that we couldn't automate. We couldn't build machinery around. And so gauging people performance is always difficult. Certainly there are times where people just aren't contributing, and that's for sure, but it's tricky. It's a tricky thing to do. But that said, I look at architects and think about their performance in terms of what have they enabled the business to achieve, following on with the discussion that we've had so far, and what decisions have they made? If we can go back and look and say, "we made this decision because we believed that it was going to have a particular impact, did that work out?" And just like any kind of knowledge work, I'm not expecting that we're going to say, "yep, 100% success," but there needs to be some level of of reasonable results that came back from those architectural decisions that, yeah, it wasn't perfect, just like any business decision is not going to be perfect. But on the whole, did the architect make choices that put us into a good position more often than not?

[00:46:40] Dave Adsit: So I don't have like the perfect numerical abstraction to use to evaluate the quality of your architects. But my My answer is going to be something around how well the socio-technical system that they are leading or guiding is delivering on the value that we need as a business. And one of the very most squishy metrics that I'm going to use is how frustrated are people who have to work with that group, that engineering group, who come from other parts of the company, other disciplines or other specialties? Are they immediately angry and defensive and upset that the product isn't doing what they want and they can't get the product to do what they want and nobody seemed to care and nobody's responding to them well? Or are they generally pretty okay with the way things are going and they just wish they could get more faster? Faster. There are a few things that I will look at consistently, and they are, they're, they accelerate metrics, right? I want to know how long does it take to go from a, we've committed to an idea, to that idea is in production, and I want that time to be as short as possible so that we can iterate as often as necessary to find the right solution to our customers problem. Like, no one is perfect. It doesn't matter how much upfront design or how much upfront discovery you do. You will never know 100% of the time that you're building the right product until you put it out there and see what people do with it. So I want to put the product out there and see what people do with it a lot. And I want to be able to change what I put out there quickly. So lead time is super critical to me. I want to know that I'm not putting out systems and then rolling them back half the time or three quarters of the time because they were broken, because we didn't take care of the the technical aspects of the system. So if I can get those things, those two in particular, fast lead times and low error rates, then I can discover what it is the team ought to be doing and what options the team ought to be delivering to the business as a whole, to our organization, whatever that is. And that's kind of how I measure an architect as a leader in a a socio-technical system.

[00:48:52] Matt Baker: I like both of those. I was, a quick joke. I was talking with someone one time about measuring engineers. They were working on some software that measured software engineers, and they were frustrated with it because they didn't think it was actually telling the truth. And they said, "applying this software to engineers is like going into a strategy org and measuring people based on how many Google Docs they produce." I always thought that was the best response. How many Visio documents do you put out? You know, how, like, yeah.

[00:49:29] Dave Adsit: I think that a lot of measuring engineers is, you might as well just line them up by height. Like, it's almost, you know, random. Measurements we put out can all, I mean, at least height can't be gamed.

[00:49:44] Allan Stewart: I bet we would find some interesting techniques to game the height requirement if that was the thing that was coming up. "Hey, those are some nice new shoes. How big are the heels on that shoe?"

[00:49:57] Dave Adsit: As a short man, I have been looking my whole life for ways to game height. And I'm not convinced I want to do any of the ones that are available.

[00:50:07] Matt Baker: You know, I like this question because I think it reveals something. It reveals, going back to what we said at the start, the role is nebulous, it's ambiguous, hard to pin down. You know when it's working, or maybe more so, you know when it's not working when the, when the business has a strategy that the technical arm cannot support or continues to fail to support, then you know you've got a problem. It's like in this zone, this role of architecture, be it a person or otherwise, as Allan's pointed out, can, can step in and help. And I don't know, like, I also reach for the accelerate metrics when I think about measuring this role, but I, it just feels similar Similar to, like, a strategy office to me or, like, an executive team to me or whatever. I just, I struggle to find an intangible. And I worry that that's an indictment of the role. You know, like, "well, if you can't measure it, then what the hell? Like, how do you know whether they're performing or not?" But it's just not that simple for me. I know that when an architect is not performing, features take forever because it's hard to ship on the system that they put together. Other. Or there's a communication breakdown because they continue to not translate business strategy into technical delivery. Like, there's some things that stick out, and, but it's harder still, if you think, like, "well, they're, they're performing well," like, how do you quantify what someone's performing well? You know? So I think the big thing that's sticking out for me on this question is, you know, if they're not performing well, like, you'll know if you have a problem with this area called architecture. And if you have an architect entitled, then obviously, like, you know, you can look at that person when things are going along smoothly, though, like, it's harder for me to gauge. I guess I would just say maybe the inverse of this, like, are you satisfied when you decide you're going to build a new product? Are you pleased with how long it takes to get the MVP out? Are you pleased with, like, the sturdiness of your application under moments of duress? You know, Or is it continually down? Like, do your fellow founders make jokes about your system because it's the one that's always offline? You know, or not your fellow founders, but do founders at other companies, like in the circles that you run in, you know, are you the butt of their technical jokes? Things like that. Maybe that gives you insight into how well your architects are doing. But on the whole, I just don't think there's an answer to this, or at least not one that I would be satisfied with if I were paying the architect's salary. I don't see a good answer yet to, how do you know how well they're performed?

[00:52:38] Allan Stewart: Well, and that's true for a lot of roles too, right? Like, even outside of architects or technology, there's a lot of things that we can't measure well. How well is a CEO doing? I don't know. We can set arbitrary financial numbers and see if those were hit or not. But I don't know that that tells the whole story either. I would add one other way that you could judge whether an architect is performing. We talked about it from the side of how the business interacts, and you started to touch on this a little bit, Matt, as far as, like, the accelerate metrics and can we deliver, but also just, like, the happiness of the software developers working with that architect. Are they complaining that the system is in their way, or are they able to do their job? So I, I have two final

[00:53:23] Dave Adsit: thoughts on this, and the first one is, maybe architecture is like Wi-Fi, no one notices or or thinks to say anything if it's going well. But as soon as it's not working, everybody in the company will let you know a few times. And maybe that's how we know architecture isn't going well is because we're not getting what we need from that role or that person in that title or whatever. And the other thing that I wanted to make sure that we mention is that you need to be very careful with how you measure and what you incentivize. Anytime we start trying to measure a role, we are creating both intended and unintended consequences with whatever incentives we put in place. And that applies to every aspect of engineering, no less so for people with the architect role.

[00:54:20] Allan Stewart: No discussion of software architecture would be complete without a reference to Conway's law. So just real quick, I've been thinking about how much our discussion has talked about that. In as much as it's a socio-technical system and we have to work with lots of different disciplines, whether we call them the business or whether together we're the business, those all feed into software architecture. Ultimately, Ultimately, it comes back to that business option of, well, how are we going to spend money and how are we going to make money? How are we going to achieve a goal and what is it going to cost us to do so, whether that's an actual monetary cost or something else? And I think it's really interesting to see how that plays out. Sometimes we fail in architecture or software architecture fails because it doesn't match up with the communication structures or with the culture of a company. And sometimes we try to change the architecture and that also fails because we want to change the architecture, but we don't have the buy-in from the business to change the people and the roles and move those around. And I think those are so tightly coupled to software architecture that we have to make sure that we at least get a mention of it.

[00:55:39] Matt Baker: My wife is in product and she often says, "so you built this amazing, great new technical system. Awesome. Did you confirm that anyone whose jobs you're changing are going to welcome it?" Yeah. Right. And I, that says to me what you were just saying. I think it's just a really clever way of observing the fact that it doesn't matter how good what you build is if the people that are supposed to be using it, reject it, you might as call it a failure. And I think, uh, I know that I've, in my career, definitely, like, uh, underappreciated that point.

[00:56:11] Allan Stewart: And if, if you're not planning on changing those things, then you've got to think real hard about what that architecture is that you're building, because if you're building it at odds, then something is going to fail or something is going to dramatically change. I mean, as far as we know, it's a law like the law of gravity, I guess. We just keep seeing it. It keeps seeming to be true and we haven't been able to disprove it yet.

[00:56:35] Dave Adsit: We won't know if there's actual gravity until we've found the graviton, right, the fundamental particle from which gravity is emitted, then we'll know there's gravity.

[00:56:49] Matt Baker: I would regret if I didn't mention one more thing before we wrap up this episode. There's a guy out in the world named Juval Löwy. He's a, has a lot of literature and thought around around how to be a good architect. And he's also, like, a super colorful person. He, um, like, at the start of some of his presentations, he'll, rumor is that he'll, like, throw glass against the wall to get your attention. Um, and the ones that I've sat in, he started off by saying, "who here is a software architect," in a room of about 900 people. And we, most of the people in that room raised their hands, and he responded by saying, "you're all a bunch of idiots." It's, and he's, all you're said something like, "you're all swimming around in your own so and so, and you don't know what the hell you're doing," or something like that. And, like, you think what you want about that intro, but that's what I mean by he's very colorful, he's very loud, and, and he'll get your attention in interesting ways, but he also taught me probably the most important lesson that I've picked up in my whole career in software, and that is to pay attention to the way things change. He calls it decomposing based on functionality or functional decomposition as, like, a massive anti-pattern. And the correct way to do that is decompose based along the axis of change. A lot of big terminology in there, but just very fundamentally, the thing that I took away from him in system design is, design your system around what changes. I'm not going to expand on it more than that because I'm sure we could spend a lot of time talking about it. But when you're designing orgs, when Allan was talking about Conway's law, right, when you're designing orgs of people, when you're designing the technical systems to fit them, and when you're trying to figure out, like, where extension needs to be in your system or where points of configurability, whatever. I think that as an architect, if you take away nothing else from this, take away this idea, or what I would say is take away this idea that things that change together, stay together. Build your systems based on the way they change and group things together based on the way things change.

[00:58:52] Allan Stewart: Thanks, Matt. With that, we'll wrap up software architecture. It's important and hard to understand and hard to really put your finger on, but we just can't do software without it. As always, we recommend joining a community of professionals by attending a software crafters group or meet up near you. The Utah SC group at utahsc.org meets the first Wednesday of each month, currently virtually. Perhaps we will talk about software architecture with you there.