Please support Black Lives Matter
in any way that you can.
Episode Transcript (Automated Transcript via @otter_ai)
George Stocker
0:00 Welcome to the built better software podcast podcast for software leaders who want to enable their teams to build better software. I'm your host George Stocker. Today, I'm joined by guest, Ben Mosher to talk about wardley mapping, then Welcome to the show.
Ben Mosior
0:16 Thanks for having me, George.
George Stocker
0:18 For folks who are just meeting you for the first time, could you share a little bit about who you are and what you do?
Ben Mosior
0:25 Well, my name is Ben Mosier. I do a little bit of this and that I kind of jokingly call myself a methodology whisperer, which roughly translates to God, I wish I had a job title because I don't know how to describe myself. But you know, roughly that means I take these methods that people are using for thinking that are relatively unknown, but quite innovative. And then I try to turn them into everyday tools. So for the mapping is one of those endeavors. There are others but yeah, that's that's what I do. I run workshops and things like that and Build resources for people to learn.
George Stocker
1:02 Now for people who are new to wardley mapping, what is it?
Ben Mosior
1:07 Yeah, wardley mapping is a strategic thinking tool. I like to think of it as like a knowledge creation tool that enables action. It was invented by this lovely old man who lives in a swamp by the name of Simon wardley. He lives in UK. And he created this method after quite an extensive bit of research into what I would basically point out as being kind of fundamental patterns of capitalism, or the mapping the practice is basically three things. It's first and foremost a visual communication method. It's about kind of creating an artifact that we can challenge and have a conversation around. That's visual. And the second thing is, it's a body of research around these patterns of supply and demand competition, you know, how does capitalism big work, how do things evolve. And then the final thing is a strategic thinking process that kind of ties both those things together in order to enable you to make new decisions based on seeing a kind of strategic landscape that most will not be able to see. So it's a knowledge creation tool in order to enable you to take action.
George Stocker
2:24 Okay, and now with wardley mapping when when you start out with it, what are you mapping?
Ben Mosior
2:31 Yeah, so when you make a wardley map, what you're focusing on are things like, you know, what is the system that you're a part of, and you can have to make some curatorial decisions about how how some curatorial decisions about what scope to pay attention to, but you could say map of business, or you can map a market. You could even map yourself as an individual But roughly what you're doing is focusing on what is the system? What is its parts? How do they relate together? And then you do two things. You think about how the system produces value for somebody, some user. And then you also think about how those parts are changing under the pressures of supply and demand competition, which is capitalism. So what is the system? How is it changing? How does it produce value for users? And is basically creates a way for you to interact meaningfully with the world by modeling it. We can get into more of what that actually looks like. But it's not as complicated or weird as it sounds. It's literally just what are the parts? You know, what do they like? And how should we treat those parts? How should we have intent with respect to each of those parts?
George Stocker
3:51 Now, how do you spend your days with wardley mapping?
Ben Mosior
3:55 So I spend time with teams doing strategic kind of training. assizes, where what we'll do is we'll kind of go through the basics of wardley mapping, we'll apply doctrinal principles about, you know, what you ought to do as individuals in the organization, how to think about, basically, what's it What's a universal principle that you can apply to the work that you're doing? That that value that you all kind of share. And then also thinking about what Simon calls climatic patterns, which is basically like, what what is relatively predictable about capitalism that if we only took the time to notice, we could actually use that to anticipate change that's occurring in the wider market. And then like finally just thinking about how to go about strategic thinking, I get more energized by the thought of getting into kind of like, what what is the you're doing George, like with this podcast and what, what are the big questions you're trying to answer? And then you and I riffing off of that, given the context of what I do, and Given the context of mapping and how I think about those things, I feel like a lot of energy coming out of that kind of conversation, and kind of nodding toward the mapping without having to like get big make it the focus so much, if that knows,
George Stocker
5:14 no, I really like what you said. And that's, that's key is that, you? I, I believe that we, as software developers, and as an as a practice, software development itself is still in its infancy. You look at you look at construction, and they have building codes and building codes and building codes. They can tell you to a tee, how much a bridge will cost and how, what it can hold. You know, who's it for? What does it does, and with software development, we can barely tell you how long a little feature will take. And that's after 16 years of doing it. And then we're
Ben Mosior
5:55 still having fights about about like whether or not estimates are a valid thing to do.
George Stocker
6:00 Exactly what can you imagine? And you're to the point about building? Can you imagine if the building codes were like, yeah, you don't need blueprints. But we built software every day without blueprints without specifications. And we actively derived teams that do produce specifications that do produce tests in the form of test driven development. Now, what I focus on is I focus on I want every software team out there to know about test driven development. And I want to make it accessible for all software developers to a point that it becomes, I believe, it can become the standard way of developing software. Now I believe that we have we have taught it incorrectly. We have glossed over the hard parts. And we have, you know, over simplified it and not gone to, when you would use it, how you'd use it, why you'd use it, who it's for, and Who it's not for, and what the, you know, the two standard schools of TDD, get right and what they get wrong. And if you go inside out as an example, if you go in that inside out TDD, you're so focused on the feature that you forget the world around you. And when by the time it comes to getting to integrating with the world around you, you you're doing it haphazardly, or you're not able to do it at all. And then from the other side, if you go on the outside in and you take in the whole context of the world, you're operating around you, you're coupling yourself to that world through the use of mocks and stubs. And there are other ways and in fact, someone named Gary Bernhardt talks about a style called FOMO, which is a melding of the two worlds you inside of your domain inside of your business context. You keep yourself isolated from everybody, and then around that, that's the functional core of your SOP of your system. That's completely done through TDD, has no outside dependencies doesn't deal with anything, databases, API's or anything. But outside of that, that that impatience. If shell that part where you talk, the world has very few entry points into your into your domain into your application. And those you don't TDD, you may write end to end tests for those, but you've reduced because all of your system is inside of that domain is isolated from the world, you've reduced the surface area that your end end tests have to cover, you know, to to the end, down to a, relatively a handful. But we as a software development community, you know, have not embraced TDD because the way that we were taught it, we were we were taught these systems that that, you know, you got three rules, they just work and they don't just work. Your mocks and stubs don't make testing easier. They make testing harder, but we we've not given enough attention to the practice and really diving into the practice of sharing its value. How How can it help your beginning software develop And we have not gotten into how it can help teams and businesses. And I think that if we we hone in on the business aspect of the value it provides to businesses as far as fewer regression bugs, faster time to market, because you're not worried about making changes to the system. If we focus on things like that, and we focus and we give each person to your point about these people or these capabilities in these parts in the wardley map, you know, software developers worry about one thing, QA worries about another business, people worry about a third thing, they worry about the value they're going to get out of this feature. But if we focus on what can How can doing TDD, give you the value that you're looking for, no matter what your position in the company is. I think we might have a better time for it instead of focusing solely on developers which is what we've been doing for the past. 20 years with TDD and it hasn't worked. It's it's demonstrably failed. So we've got to change your tactics. And that's why I am here. That's why that's why I care. I believe that all software teams can produce value and produce more value for their customers faster. And I believe that software development itself must change. It must adapt to the world around it. And it must produce some sort of standard in order to be able to produce software reliably, which we still can't do. And I think that something like FOMO style of TDD will get us there. It will give us much closer it may not you know, it may not be the the end thing, but it is the next thing.
And that's what I that's what I help teams do.
Ben Mosior
10:46 Yeah. So it's like the Faux-O Manifesto, right? No, yeah.
George Stocker
10:50 And it's not like it none of this is original to me. Like I learned about it. When I went to PyCon in 2012. Gary Bernhardt was on stage. And he's he's talking about it in the context of his own site, destroy all software, and in the context of it and its billing mechanism. And during this, I was watching it unfold. And I had been well versed in to that point both from the inside out perspective and the outside in. And I had, I had been dealing with all the problems that he talked about mocks and stubs and how brittle they were. Because once you start mocking something, you're now you're not coupled to it. If you're mocking a method, you were coupled to that method being called. And it bothered me because we would get failures in our test suites for no reason other than, hey, we took out this implementation detail, no longer calling this method inside of, you know, these three other methods. And that would break the test and it shouldn't break the tests. But in his talk, which is called boundaries, he goes through, you know, this is what functional core imperative shell Looks like this is how you can model your system. So that you you return primitives inside inside of that functional core. You don't mutate objects, you stay away from the Oh, which is I have one object I mutated state. Now you always return a new object with that new state, and you never mutate objects. Also, you deal with primitives, you don't deal with how external for instance, the Active Record pattern would return you an object, you don't deal with that you deal with your own method of object retrieval. Now it turns out the shell side of it when you do have to talk to the database, you're going to have to deal with that mapping. But inside of your domain, that mapping is entirely your domain objects, your primitives that don't have external dependencies, and you start there. That's how you decompose your system so heavy into it. Domain driven design flair. Understanding your bounded contexts of understanding your domain, and of speaking in the customers language. Now from all that you can, from all that you can make sure that the actual business work that your system does is testable and is fully tested through test driven development. And then your, your, your shell, you know, the delivery mechanism of your software is the thing that you need to write end to end tests for. But that's, you know, that's an API endpoint or two, that's not, you know, trying to have that API endpoint do all of the internals of your system as well.
Ben Mosior
13:42 Yeah, what I'm what I'm so here's a, you know, here's an admission, right? So I'm a former systems administrator. And I have, I'll be honest, I couldn't tell you the difference between them. I couldn't tell you the difference between a stub and a mock I will set a mob and a stock and I'm not
George Stocker
13:58 sure They should have named him that.
Ben Mosior
14:01 Yeah, honestly. No. But like what? What's interesting though is I heard you do something that I hear people do when they learn wardley mapping. I heard you disambiguate a term that is used almost ubiquitously. So test driven development, right? You You took that thing and you made it two things. And then you talk me through how each of those things is used in different contexts. And then you described that as a third thing. So test driven development is now three different things. It's inside out outside in. And then the third one, which I of course, have no idea what the name is called, but it sounds like fun to pronounce.
George Stocker
14:42 Yeah, the Gary Bernhardt calls it Faux-O and it is, it's exactly a third way to do TDD. Yeah. From wardley mapping with with test driven development. Would there be a way to map out you know, a team adopting TDD Through wardley mapping?
Ben Mosior
15:01 Yeah, it's really the question like, how would you ever be able to have the conversation? Like, what conditions would you have to create to have the conversation where you could contextualize each sub practice of TDD into a context that you in a way that you would enable you to know when to deploy? Which one? And so like, you shift the conversation from which one is right, always, to which one is right, in which case? And what conditions would you have to create in order to have that kind of conversation? And and frankly, the answer without something like wardley mapping is luck, to be honest, or really like incredible intuition, perhaps. And kind of like I know, we were talking before a little bit about like human shock absorbers, sometimes the embodied kind of cognition that people have, they have these like, tacit things that they just know without being able to explain and so sometimes they'll pick up on something like that and able to have the right conversation. But like, it looks an awful lot like luck to me. So I would rather have a predictable way to create conditions for conversations where we could disambiguate, like big, messy things like TDD into context specific deployment of specific methods. Now, I just used a bunch of $5 words. So I'm going to like, take a break, and pat myself on the back. Let's let's get really like concrete. This is this is what you did. You took TDD, you split it apart. And then you said, in one context, do this in another context, do that. That's what you what you did was you had a struggle of ontology. What is test driven development? And you You brought in a language of existing models, which is exactly what you can do when you're getting started. You're like, Well, okay, the thing that is test driven development actually turns out to be several different things. And so when should we use one over? The other is an interesting question. So just just pointing out that there are multiple things enables you to actually say, Hey, we should use one in one case in another in another case. So so what what happens next? Like what what are you thinking about?
With respect to like?
George Stocker
17:23 Yeah,
Ben Mosior
17:24 actually, here's the question like, how would you create, like, currently create the possibility for that conversation? Like, how would you enable a team that you were managing to have that kind of conversation?
George Stocker
17:39 Yeah, so for me, I'm always interested in the bottom line in what will this do for me or for the team for the business or for the customer? You know, we adopt TDD. What's Why? Like, why are we doing it? Are we doing it because we have Lots of regression. When we deliver code, are we doing it because we find it hard to change code? Are we doing it because we, you know, heard on a podcast, it was good idea. Why are we even doing this thing? And that's the first question that I want to answer. And I want to get that down on paper.
Ben Mosior
18:17 Most of the time, the reasons people are adopting things is fashion and tribalism. Right? Yeah. It's what what's awesome is that's the phrase that I stole from Andrew clay Schafer, but basically, it's like, what's really cool that people are talking about that gets me excited, because, you know, what have you liked? hundreds of companies are doing this. So we should do it to or, you know, our group of people who believe this thing versus that group of people that believes in that thing. nobody's asking what test driven development actually makes possible for us. When we have it as a capability in the organization. What does it enable for us?
George Stocker
18:53 Yeah, so for what I've seen is when you when you Do TDD and you use the right and and you went you, you hit on it earlier. And you really hit on the center of that is that not all forms of TDD are acceptable in all situations. But when you apply the right form of test driven development, to the right situation, to the right code base, you give yourself give the team confidence. So if your team is lacking confidence, or you have a lot of new developers on the team, you're giving them confidence that when they make changes, those changes won't break anything else, which, as a developer, new to a code base, that's the first thing I'm thinking of is I don't want to be embarrassed in front of my teammates, because I just made a change, and I broke production. I don't want that to happen. From a business's perspective, you're gaining the confidence that you can deploy at Friday at 5pm. You know, there's that mean, you don't deploy on Friday. And if you have a testable system and a system that is tested, you you gain that confidence of Hey, I really need this fix to go out right now. Can we do it and you as business you can. Now you To start to answer yes to that question, from a system perspective, from a maintainability perspective, you're now looking at, there's an I see it every time I'm, I'm with a new team, it's the desire to rewrite this desire to get rid of this thing and to replace it with this magical new thing. That is so much better
Ben Mosior
20:21 problem of discipline to write, it's like, it's like this assumption that like, hey, if we just rewrite it again, it'll be fine. And so you start this, this whole new effort without having all of the understanding or the skills that would make writing good software possible, expecting to get a different result. And I do believe there's a word for that George,
George Stocker
20:41 it's called insanity. And I've been guilty of it myself. And I've also been in situations where you know, the rewrite decision was made before I came in and I was asked to implement rewrite and say, Look, and I had to keep saying like this is not going to go the way you think it is. Because the rewrite you don't have the people who produce the original system. Usually, you don't have the original context. And you don't know all the cases where the system is in use, like you. There's a semantics, Twitter account that I love. But it's basically like the it tweets out, you know, things that are real in systems. For instance, the system does what it wants to do. It's not it has its own agenda. But you don't know those things when you rewrite. And you just think that the system is what you see in code, instead of the whole context.
Ben Mosior
21:31 Not to mention that oftentimes the business doesn't even know what the software is supposed to be doing. The business probably couldn't tell you how the software actually fulfills user needs in a way that produces profit for the organization. Because like, this is this is like unintentional ality, which is a word I'm going to make up for whatever reason, like it's the absence of being intentional. Is it all the way down? It is it starts at the highest level of the C suite. It goes all the way down into our engineered engineering organizations, product organizations, operations organizations, it doesn't matter where you look, you're going to find this disconnect. And so the question becomes like you as a software developer or us a software leader, trying to make an informed decisions with respect to this entire system, unintentional ality, it becomes really, really hard. And so of course, it just, it starts to feel like a well, ah, it's a mess, and we didn't manage the legacy well, so I guess we should just rewrite it because that's at least going to be approved by the business as like a panacea, right, or a panacea that's gonna at least be approved by the business as a cure all for the problem, because, you know, they don't know any. They don't know any better either.
George Stocker
22:48 Yeah, and sometimes it might be there are instances where a rewrite is the best thing for the team. But, you know, for for businesses that don't want a chance to rewrite information. teams that have the situational awareness to realize they don't know what they don't know about the system, introducing characterization tests to figure out what the system does. And then from that, you know, producing test driven development tests, you know, to port over new functionality to put it under test. And then gradually refactoring the system using those characterization tests, refactor parts of the system, into something that you is produced, or can be maintained through test driven development helps. But that goes to those three different types of test driven development. You know, if you're producing a new feature in isolation, and then you integrate it later, maybe inside out as your best way to go worry about your feature, worry about what it does, specify it through tests, implement those tests, or implement the test, implement the code for the test, and repeat that. You know, that's best when you have a feature in isolation and you're not as worried about trying to integrate it into a larger system. Whereas outside in or, you know, introducing mocks and stubs and mocking out things you don't own or stubbing the state of the system, or stepping parts of the system that you're using. That's good when you're trying to take something existing and put it under test. It's a good first step, the problem with mocks. And I said this earlier, the problem with mocks is that they tie you to an implementation. You know, I verified that this method was called Yeah, in refactoring might end up removing that method. And if we're not careful and don't realize that it's being called in this test somewhere by dependency, it's going to fail, our tests will fail, even though nothing changed behaviorally. And then that introduces that next third style of test driven development FFO, which allows you to then test the behavior of the system and not worry about the implementation. I'm testing the behavior of this billing reconciliation feature. I don't know care what methods actually get called? All I care about my input is, you know, this this bill, the state of the system is this bill is in a certain state and all I want to know is, you know, is it reconciled or not. And with that you can then change a lot of the implementation, and your test don't get affected by it.
Ben Mosior
25:20 Yeah, one of the things that seems really critical in designing an organization, let alone designing software, which I mean, Conway's Law is a thing, but like, roughly speaking, where are the boundaries between the parts of the system, and very quickly in both an organization and in software, you start to realize that entangled pneus is one unnecessary evil, but also something that shouldn't be allowed to dominate as as an extreme or a default. Right. So like, what I mean by that is like tightly coupling things right where, like, you're being tied to implementations is probably not a great right thing to do, if there's a chance in the future that that thing has to change, right? So you have to pay attention to change. And if like, it's a 5% chance that that thing will have to change in 20 years, then maybe who cares, right? But like, if there's an 80% chance that in the next six months, there's going to be security vulnerability that requires you to actually adjust the implementation in a way that would have, you know, cascading effects and all the other parts of the software, then then, yeah, maybe I should be a little bit more concerned about being tied to an implementation in that case. So one of the things that I really like so wardley mapping really points at this idea of interfaces, and and cell based structures, both for organizations but also for, I think, in particular software. So So what is the interface? How do you create those clean lines, and unfortunately, there's like this whole body of skills that you have to build in order to do that. You have to be comfortable. Like taking a decent guess, under circumstances of ambiguity, where to draw lines, what to include inside the boundaries and what to push outside the boundaries. And if you're not careful, what you start to see is that in an organization, say between a development organization and an operations organization, you'll notice that there are things that get stuck between those two saw, like sets of things in the organization, that they're just, you know, crust that stuck somewhere, and nobody's responsible for it. And so it starts to decay and it starts to smell. Similarly, in software, if you don't have clean lines that, like, make responsibility for each part of the software clear, you really start to notice how like that is the zone of no maintenance, that those are the things that will not be touched. And that is equally applicable to organizational theory, from simpler like people's in teams.
George Stocker
27:57 That's right, and you're going to get it Wrong. That's one reason if you use domain driven design, and you think about your bounded context, which is you know, inside of this context, a word means what it what it means. And outside the context, this word may mean something else. But in this context, the word has a specific meaning it's not going to change in this context. If you use things like your bounded context, and the domain, the language of the customer, the language of the problem you're trying to solve, you, you start to see where, where things are defined, and what they relate to. And you start to see those those boundaries crop up just from when words change, meaning. You know, change management means something completely different to a business person than it means to me.
Ben Mosior
28:46 And it means something very different to a consultant as well.
George Stocker
28:49 Yeah. And so, you know, when I know that word has changed, meaning I know I've crossed a boundary of some sort, and you're going to get it wrong. One of the tenets of TDD is that you don't start out with the right You don't start out with the right architecture, you're going to evolve to it. Because you're going to learn every time that you add a new test to test out a new feature, or you add a new feature, the system is going to change shape. And you'll figure out you know, what the system and you know what it should look like, through that evolution because you don't like you're never going to know less than you know about something at the beginning. So if I'm, I got a new system, I will never know less than I know about it right now. You know, every moment I will learn more and more and more. And you hope that when you learn more and more more systems easier, easy to change, it's not easy to change, like that's a that's a smell,
Ben Mosior
29:43 that it's a huge smell. If for example, like you need to do a lot of exploring, right, actually, this is where the wardley mapping concept of evolution starts to become really helpful here. So like, we may or if you if you've looked at wardley mapping, you know, there's a This x axis kind of like idea of evolution, right? four stages from Genesis to custom built the product and commodity, you can also look at that through the lens of like practices. So like emerging, sorry, novel practice emerging that novel, practice emerging practice good and best. And so there's this progression from left to right. And like how evolve something is changes the way that you should treat it. So for example, things that are in like the first couple stages of evolution, so Genesis or custom build, those have to be easy to change, because they're so uncertain that you, you almost have to assume that like nine times out of 10, you're going to do the wrong thing the first time. And so that's where you start to see things like agile being really helpful, where you're basically trying to lower the cost of change of that thing, so that you can change as many times as necessary until you find the value, as in find the right form of the thing that produces value for the people that you're serving, by building the thing in the first place. Now that's completely different from say, like, if you're looking at something like a login function, right? Generally speaking, authen off z, like these are things that are broadly understood. And for you to reinvent that wheel, and to pretend like you need a low cost of change, and the need to rapidly change around logins, is kind of absurd. If you compare that to the way that the rest of the industry treats that kind of practice. And so there instead of reinventing the wheel and using an agile method, that you might actually want to just adopt something, either in terms of the design or in terms of an external solution, because it's so well understood. And of course, you're going to have trouble like adapting it to your local context to your software. But in truth, you don't want to be have to be the expert in that thing. And a high cost of change is okay, because the thing isn't going to change in 20 years very much. So it's like trying to understand how do you continue Realizing practice? How do you contextualize, like each of the different sub practices of TDD? What does each thing depend on? What does each thing? What depends on each thing? It's like you look up, look down. How does it How is it situated in this larger scope of things, such that you could make those nuanced decisions without just reverting basically to like, my way or the highway kind of approach?
George Stocker
32:27 That's really interesting, because as you're describing it, I'm seeing, you know, both the forms of TDD. And when they would use animal types of systems and on what aspects of the systems like I'm seeing that overlay onto the workday map. So something that, you know, is going to change a lot. I mean, want to put a lot of effort into making sure that that part is designed through TDD, but something that interfaces with the login mechanism that's over on the commodity side of the working map. I may not I may only want to have an index Test around it and automated an automated UI test around it. I may not even want to deal with that from a, from a developer. I'm writing tests for this perspective, because it's, it's not in the novel. Or the emerging, it's, it's over there on the commodity side of things.
Ben Mosior
33:24 Yeah, it's like, how certain is it? And do you really need to doubt that it's working? Now, it also depends on like, your organizational context, like if this thing doesn't work, what are the implications? Right? If this thing spits out garbage data, you know, what are the implications of that, like, Are people going to die? Or is it just that, you know, someone gets a 404 page when they weren't expecting to, right so, and that's where you start to notice that. Look, the whole system of software and the organization building, the software is A bunch of little negotiations between different parts of that system. And so that's when you start to find that things like SRP are really interesting. Because it explicitly calls out that negotiation as a function of
George Stocker
34:15 site reliability engineering.
Ben Mosior
34:16 Exactly. Yeah. And like, just, if you go read the free, like just the one chapter from Google on, sorry, about s ellos, and SL eyes, like just go look at that chapter and think about what it means to negotiate a boundary like that between operations and development, for example, you start to recognize that this this whole thing, all of this that we're doing, like we might think that software is like, understood or understandable. It is one giant human mess, and that's actually okay. But we should probably be careful about where things are more or less uncertain. And if we more explicitly have the kinds of caution conversations around negotiations between the boundaries of these components, we can actually start to be more intentional about how we're treating each thing. Like until we can build a software system that doesn't turn into a giant ball of yarn, in like a giant tangled knot. Eventually, if until software systems are not inevitably going to result in that kind of end up in that kind of state, I have a really hard time thinking of software development as something that's known.
George Stocker
35:31 Yeah, that's you would you put it on the emerging end of the scale,
Ben Mosior
35:37 possibly just to be a pain in the ass? But like, I think that it's an interesting question. And when you break down software development into its hundreds and hundreds of different sub practices, asking the question, what is software development becomes not super easy, and every single one of those sub practices is somewhere else. along that spectrum of evolution. And unless you're aware of that, I think you'll be reinventing the wheel for the foreseeable future.
George Stocker
36:09 And now we're really getting into the value of wardley mapping. As a software leader, I can use it to contextualize my team, our practices, our relationship, business. And I can, you know, give myself a view of where are we at? What are we doing and how does it fit
in this larger context,
is a way to visualize you know, what is as opposed to what we want it to be.
Ben Mosior
36:42 Yeah, it's really interesting because it enables Conversa- it like once you start sketching out artifacts like this. You can look internally and say, Okay, how should we be behaving like how should we treat this set of components, and then you can compare that to the way that the larger market treats that component. And you can say, Okay, well, how is everybody else doing? Especially in like public sector, like public sector can learn from private sector, for example, and go like, what are our counterparts in private sector doing? Like maybe they're not bound in certain ways that we're bound. But can we at least like learn from the way that they're doing, like authentication or something like that, right? You, there's a lot of learning that you can have just by looking outside of your organization and doing basic like open source intelligence gathering, like, read the press releases of other companies, when they talk about the thing that that is somewhat related to what you do. And you learn a lot about how different people view that same thing. But then you have to talk about time. Because if you notice a gap between what you're doing and what others are doing, and that gap isn't valuable, like it's not differentiating, it's just a waste of time. So for example, if your custom building a login function, I know I keep like hammering on that example, when you should probably just be adopting a library. It's gonna it's gonna take Little bit of work for you to get from point A to point B to actually resolve that bias. And so when time starts to be involved, you end up comparing like your your desired internal future state against where the rest of the market is going to be in, like, however long it's going to take for you to make that change. Because if you, if you set your ideal future state internally, to the current way that things are externally and the world keeps changing, then you might embark on a big heavy lift for nothing if the world changes significantly enough for your change to be out of date. I know this is like a really hard way to like, explain the phenomenon but it's like, that's what happens to most organizations when it comes to business strategy is even if it's just a gut feeling. By the time the organization actually implements the strategic initiative, so to speak, though So the world has moved on. And that may no longer be the right thing. So like this whole, like, unless you can have conversations about how to tackle that problem, like, I don't see a lot of hope for the for the quality of decisions being made, either in terms of the software that we're building or in terms of the strategy that we're implementing in our businesses.
George Stocker
39:22 Now, for software leaders, I think those conversations less on the business side, or more on the, you know, what tech stack should we use? What database should we use, you know, what practices should we adopt among our team? building software? A thing that I see is that, you know, they try to answer those questions first, instead of answering those questions after they've done what you've suggested, which is figure out strategically as a business. Where do we want to be? Because once unlike, unlike other, unlike code, if you're using a data store, You're going to become coupled to that data store unless you're very, very careful. And I've not yet seen it seen a team that was careful enough not to become coupled to some aspect of their data store. And so, you know, if I'm sticking around and I choose Mongo, and I say, Well, you know, we're going to use Mongo. And then, you know, two years later, there's that nice article about how Mongo lose this data, like, Oh, we need to get off Mongo. Well, we're pretty coupled to it. That's not happening. But it sounds like with wardley mapping, you can we can, we can situate where we want to be strategically as a business, we can orient the software team towards that ideal future state. And then from there, you make decisions
based off those factors.
Ben Mosior
40:47 Yeah, I think for software leaders in particular, what something like wardley mapping enables you to do is to be intentional, you know, local way and I bet We just mean, when you look at all the parts of the system that you're responsible for, do you have an intention for each part. And that's, that's a serious obstacle for most. Because until they until they are able to actually grapple with all the parts of the system, they're not going to be able to make sense of it in a way that together, it is like a coherent strategy. And in particular, I think like software, leaders need to have that kind of intent. Because otherwise, they're going to become subject to what I would very lovingly call meddling from other parts of the organization, not because those other parts of the organization are bad or anything, but it's more like they just have priorities, and they have things that they think they want. And if you're about to make a new decision about either what data store to start with, or whether or not the news that mangos losing data, for example, is a significant enough. No impetus to actually change the data. Or if you if you aren't prepared with local intent for each part, then you're probably going to end up being swayed by the political winds. And you'll be making decisions based on other people's feelings. And I for one value feelings, but I don't think they are necessarily the primary way that you make decisions, especially decisions with impacts that lasted many, many, many years. So, when I think about this, I think it's strictly about being able to, to understand why you made the decisions that you made, especially when others around you aren't. When they aren't sure about those decisions that they they're making. This is a really like, messy thing, because you soon start to realize that like wardley mapping in particular looks like just a like, Oh, it's just another diagramming technique. And I know the DDD, people seem to like it as well as an approach and like, I'm encouraged by that. But like, what I think is like the, what I think is hidden underneath the surface of all that is
it's all about conversations.
And in particular, it's all about conversations about deep social problems inside the organization that are not going to be obvious that you can't exactly code your way out of. And when someone comes to you and says, I want to do this, and it's it's a bad idea, but you don't have a reason to say that it's a bad idea other than it just feels wrong, you're going to lose.
George Stocker
43:40 But wardley mapping can help you show why it's a bad idea in context.
Ben Mosior
43:46 It really like boring mapping is one tool and I in a huge set of tools that can help you be more intentional about the work that you're doing. I for sure, have experienced circumstances where by mapping out of space Honestly, one of the one of the typical experiences is you map out a space and you go, Oh, no, I made a decision A long time ago, that really is hurting me right now. And frankly, like the early, you rip that band aid off better. But once once you've reckoned with it, you start to recognize that you have an intent.
And when you have an intent, you start to care about it.
They make sense, I should do this this way. This is what I'm trying to do. And And ideally, you're having that conversation with other people around you in a way that brings them along and help them even challenge some of your ideas using some of the this kind of language like, well, what, okay, yeah, you want to choose Mongo, but Mongo entails all these dependencies, is that going to be right for us? And if you can't answer those questions, then you know, then that was an effective challenge and you've all learned something now because you'll go off and find out what you need to find out in order to answer that question. But otherwise, the other way that this works, sometimes it's just that people are will be making decisions based on their feelings. And they'll try to impose those decisions on your organization. And especially when you're in charge of an organization, that leg is full of other people. When their lives are disrupted because of someone else's feelings in the organization, you know, that's gonna really hurt morale, especially if it doesn't make logical sense to them. If you can't help communicate intent from other areas of the organization and make it make sense, then you're just going to produce an organization that is just doing what it's told, instead of thinking actively about how to make good decisions in terms of building software.
Sorry, it's a bit of a rant but like
George Stocker
45:50 no, that's that's great. And that's that gets to the value that you provide in teaching teams. wardley mapping is that you can help them ensure that their teams are
Producing software intentionally by mapping out where they're at.
Ben Mosior
46:03 Yeah. So here's what I'd say, if, if some of the things that I made that if some of the things that I just said, even if they don't make sense, if they're intriguing to you, then what I would highly recommend is go to learn more the mapping calm. And just click around a bit until you find some things that are interesting to you. And if you decide that it's interesting, go read the book, ask me questions, you can email me either through the website or by emailing Ben at hired thought, calm, reach out and tell me what's going on and I'll help you get started. Like I love helping people start to make sense of their worlds with this stuff because it betrays my optimism even. Even now, it betrays my optimism around how if people are just more intentional, I think they'll bring more good about about into the world.
I want to help you get started. So
contact me say hello, ask questions. There's a lot of good resources just to start getting exposed to the method. And what I'll have to say, above all, do it like actually sit down with a piece of paper and follow the steps and try to do the process. And if you don't learn something, I will be surprised.
George Stocker
47:24 I think I'm actually going to do that. I'm going to sit down and I hadn't done it yet. But you'd sent me some materials on wardley mapping. I'd like to sit down and put test driven development in that context and see what that looks like. But then this has been this has been an amazing time. You know, people can find you online at learning wardley mapping calm and they can email you then at higher thought.com. Are there any other ways that people can find you online?
Ben Mosior
47:53 Yep, I'm on Twitter as well @hiredthought.
I was going to say something self demeaning Because I hate that handle, but here we are. Branding is branding. Yep, I'm on Twitter @hiredthought. And I'm pretty accessible on there. What I'll say right now is like we're recording this on June 3. And you know, the United States is hurting. And I think a lot of people are hurting in general. And what I will say is like, right now, I'm not tweeting so much because of that context. I want to be respectful. But if there's one thing that you could do, even if you don't care at all about wardley mapping, if there's one thing that you could do that would help yourself and help those around you, it's learn a little bit more about race and the context of race and the way that it manifests in the United States. And what I'll say is that include this in the show notes as well. It's a URL to a list of books and other suggestions by Tatyana Mac. You can access that URL by going to https://lwm.events/race. So I opened up a page with some books that I highly recommend you engage with. And I'm currently reading The New Jim Crow. And frankly, I am learning about some things that I didn't know before for the first time and I'm kind of ashamed about that. So, use that shame for good. Don't let me be shame. shaming myself in vain. Go learn about race and learn why this country is experiencing the anger that it is.
George Stocker
49:32 That's, that's critically important. Anybody who's watched my Twitter feed over the past few days is just just seeing retweeting and showing what's happening in these protests and how the protesters are being treated by people in power. And I second and I will put the show notes, Tatiana's work. I've read some of it. I'm buying the book. That she's linked to not on Amazon by buying the books that she's linked to. And I second it's, it's really important I struggled whether or not to bring up the we are indeed recording this on June 3, two days past the point where a sitting president ordered military or civilian cops to clear out the area right in front of the White House for photo opportunity. And just that, whether or not you agree with that actor, not just how historic and context changing that action is, you know, what it represents? Who would effects and more importantly, what it says about us as a culture as to what we allow and what we don't allow. And that's not even including all of the really important events that have happened, up until this point, that we as a culture have not yet learned from. We've not changed, we've not improved. And hopefully these protests mark a turning point where we as a culture, take a good hard look at ourselves at our at our past and say never again and actually live the values that we claim that we have. On that note, Ben, it's been it's been a pleasure talking to you. Thank you for taking the time out of your day
to talk with me, and
all right. Alright folks. That's it for today. I'm George Stocker, and I hope you'll join me next time on the build better software podcast. Thanks