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:25] 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? Why does it matter?

[00:00:44] Dave Adsit: Well, architecture is indeed nebulous. I've heard it described in a lot of ways. One of them 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. 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 or people that go into a shop that needs a little shopping cart and they end up shipping them like 40 microservices 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 talks 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:16] 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? 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 complexity?

[00:04:07] Matt Baker: 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, two 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 can't get rid of it. And then you start trying to shoehorn 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. Really like the idea that software architecture is only known in retrospect when we see what parts of the system ended up working. 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 the TCP connection handler. And maybe what mattered was the interfaces between the microservices that the different teams all agreed to.

[00:05:47] Matt Baker: So. 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 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 dollars 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 the that function gets 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, 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 obviously you're the same thing? And what is it? It's driving this point for me. How you determine a successful architecture. What parts of your architecture? Matter? 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 pivot quickly? I don't 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:28] 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 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 is super important for the architect to be someone who is considering that bridge between. Yeah. 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 or, 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, you know, a 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.

[00:10:14] Dave Adsit: Inclusive way. Yeah. 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:46] 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 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. 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 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 real thing. And I think that's 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, I kind of like it because so like I agree, it's an aspiration for a lot of engineers 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 this startup. And the clarity I got from that experience was I really enjoy using my technical skills to push the I was going to say the business. I really enjoy using my technical skills to grow the company. Yeah. 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 a lot of satisfaction with 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. I've worked 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 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. stuff it's not satisfying for me like I want to be solving a hard problem that yields fruit that I can see and 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 money or saves them a lot of money or positions them to 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 this 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 the Venn diagram overlap if you will with our technical posture I'm going to play there like 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 sales people I might go out on sales calls I might go sit with support I might go sit with product marketing and 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 that yes they have all that technical prowess but it's really not the time to flex it in that way you know 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:15:59] Allan Stewart: I like that having 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 you know Egyptian pyramid like structures where you know maybe that's not so good maybe that's not the best way to deliver business impact

[00:16:43] 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 mirrors 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? 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 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. You know, 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. For whatever, whatever goal you're pursuing, the architect would say, OK, well, here's here's your five options are all vetted. Here's your tradeoffs. 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:30] 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. You know, 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

[00:21:16] Allan Stewart: successful changes over time. 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? You could do nothing, which is also a decision because the world will continue to change. And, you know, 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, you know, legacy COBOL systems, for example, or, you know, around the turn of the century, there's a lot to do about Y2K and what is this going to mean for all these businesses that are built on these old technologies. In some ways, it's terrifying, like, 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. They're not going to be able to 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 that are going to change. 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. You've said something there that's really,

[00:23:16] Dave Adsit: 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 a software, we're going to put in the design 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 of the system. 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 configurability. Reuse? Yeah, reuse. Yeah. It's so dry it chafes. As I was thinking about this podcast episode, I was thinking about some anti-patterns I've seen architects adopt and one that's so close to ubiquitous, 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. 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 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 one. I don't mean to belabor this point, but this thing 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 tradeoff game all the time of cost of investment versus payoff. You're always looking at what's the best way to solve this problem. Jim Grant The devil's in the details the best. That's a hard question. It takes a very astute technical mind, I think, to be able to navigate those, especially as the company grows. Going back to what we were saying earlier, it's a great way to take your technical skills and start flexing them in a new domain. But it's unsexy, and I get it, sometimes unsatisfying to solve the problem quick and dirty, but oftentimes that's the right case. Going back to, do we need an architect? Jim Grant 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 or configuring low-code tool or something, they're participating in software architecture. Nielsen Nielsen Nielsen Nielsen Nielsen Nielsen Nielsen Nielsen Nielsen Nielsen 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? So holding that train of thought, Allan,

[00:28:14] Matt Baker: how would you field the question, do we need architects? I mean, I would say, yes, you need

[00:28:19] Allan Stewart: 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. It's impossible. 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 just no way to communicate.

[00:29:34] Matt Baker: Yeah, I agree. It's a total loaded question, right? Because it ignores the other variable there, which is how much it's 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 given a different position. You know what I mean? And I'm not quite sure why. If you gave me a couple of beers and said, Matt, what's your unfiltered, super biased stance? I'd say, well, the execs just... Never valued my opinion. And that's a pretty sob story position. They just didn't listen to me. Had they just listened to me? And so I don't think that's right. I think that's more like catharsis than answering it that way. But there's probably an element of truth there where just because the technical track observes this as the top of a particular technical track doesn't mean that anyone else agrees. 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 lean on you to help us understand what's technically feasible. 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. I could go through and cite a bunch of... Matt Odellus I could point fingers, I'm sure, at a lot of different reasons, but 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. 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. Matt Odellus 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 your 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 And that's 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.

[00:33:36] Matt Baker: That's right.

[00:33:37] Dave Adsit: 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 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 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:23] 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 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 wants to counter offer on this, or the bank is saying this, here are your pass out. And she'll give me the, 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 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 a some amount of acreage. 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 a Matt professional. She's not here to tell Matt exactly what he needs in his life to be fulfilled. And I think there's an analogy there with software architects and how to be a good architect and just recognizing the fact that there's certain things that you don't extend to. But as an architect, considering the analogy I've just raised, imagine let me tell you about how you should play in this industry. Josh Woodbridge 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. Josh Woodbridge So this is the nature of their job. Josh Woodbridge 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 a foul pretty quick. And I think we do this all the time, myself personally. And so a good architect, I think knows how to Josh Woodbridge 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. 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. I think that to me, given my experience and where I'm at now, I think that's an architect. That's at least a quote unquote, good architect. And it sucks because it's acknowledging that you never cross into being seen as someone that's helping steer the 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

[00:37:38] Dave Adsit: it. 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 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 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? I think it's 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've got one of the best 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 they're 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 a technology path more skeptical of us as the expert with the secret knowledge who is trying to manipulate them. And that, I 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. Yeah. The ruler is always a little

[00:40:31] Allan Stewart: skeptical of the scribe. I will point out that we're talking a lot about business. I think that these apply equally as well to other kinds of projects. 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 that's just naturally where the language goes. I also want to indict leadership

[00:41:02] Matt Baker: 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 as 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, And if I don't get a clear answer on that, I'm out. 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. 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, I don't know why that happens, but, but I, 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, you know, 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, 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 unwinnable situation.

[00:43:45] Allan Stewart: 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've 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, maybe I'll just pose it to you too, Allan and Dave. How 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 and 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, a hundred percent success, but. There needs to be some level 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 architecture. way of changing the way of changing the way of changing the way of changing the way of changing the way of changing the way of changing the way of changing the way of changing the way of changing the way of 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? There are a few things that I will look at consistently and they accelerate metrics, right? I want to know how long does it take to go from 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 customer's problem. 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 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 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. And that's kind of how I measure an architect as a leader in 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?

[00:49:26] Dave Adsit: I think that a lot of measuring engineers, you might as well just line them up by height. It's almost random. The 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 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 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 step in and help. I don't know. I also reach for the accelerate metrics when I think about measuring this role. But I, it just feels 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. 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 in 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, you're going to have to be able to do that. So, you know, you can look at that person. When things are going along smoothly, though, like, it's harder for me to, 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, the sturdiness of your application under moments of duress? You know, or is it continually down? Like, do your, do your fellow, like, founders make jokes about your system because they're not doing it? 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 they, are they, are you the butt of their, 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 performing?

[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. Now, 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?

[00:53:21] Dave Adsit: So I have two final thoughts on this. And the first one is maybe architecture is like Wi-Fi. No one notices 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 mentioned 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 one another. And so I think that's a really important thing to be aware of. 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, 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? And 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 well call it a failure. And I think I know that I've in my career definitely under. Appreciated that point.

[00:56:11] Allan Stewart: And 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. 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 Yuval Lovie. He's a has a lot of literature and thought around how to be a good architect. And he's also like a super colorful person. He. 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. 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 his hands, their hands. And he responded by saying, you're all a bunch of idiots. And he's all your 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 he'll get your attention in interesting ways. But he also taught me probably the most important lesson that I 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 decomposed based on the axis of change. A lot of big term. I don't know if there's 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:53] 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.