Episode 036: Metaphors and Microservices with Matt Stine

Panelists:

Coraline Ada Ehmke | Sam Livingston-Gray | Rein Henrichs |
Astrid Countee | Jessica Kerr | Janelle Klein

Guest Starring:

Matt Stine: @mstine | mattstine.com

Show Notes:

00:16 – Welcome to “Chinchilla Chat: Where It’s All Chinchillas…All The Time…” …we mean, “Greater Than Code!”

Want to help make us a weekly show,
buy and ship you swag,
and bring us to conferences near you?
Support us via Patreon!

Or tell your organization to send sponsorship inquiries to mandy@greaterthancode.com.

03:10 – Matt’s Origin Story in Software Development

09:04 – The Business of Consulting

16:24 – Empathy in Consulting

20:07 – Rigorous Communication and Shared Language; Microservices

Ludwig Wittgenstein

Sapir-Whorf Hypothesis  

Metaphors We Live By

39:05 – Ubiquitous Language

Surfaces and Essences: Analogy as the Fuel and Fire of Thinking by Douglas Hofstadter  

Coraline Ada Ehmke: Metaphors Are Similes. Similes Are Like Metaphors.

Wittgenstein’s Ladder

Performance of Genetic Algorithms For Data Classification by Matthew Stine

Are you Greater Than Code?
Submit guest blog posts to mandy@greaterthancode.com

Reflections:

Matt: Ludwig Wittgenstein and language games.

Coraline: The shortcomings of pattern-matching.

Astrid: Using evolution as a model.

Rein: The Beginning of Infinity: Explanations That Transform the World

Janelle: Language as a mechanism of control.

Sam: Building a bridge of understanding with progressively less incorrect metaphors.

Please leave us a review on iTunes!

Transcript:

SAM:  Hello and welcome to ‘Chinchilla Chat: Where It’s All Chinchillas… All The Time…” I’m Sam Livingston-Gray and here with me is my fellow chinchilla, Jessica Kerr.

JESSICA:  [Producing squeaking sounds.]

[Laughter]

JESSICA:  I’m not going to correct you, instead I just like to say how happy I am to be here today with Astrid Countee.

ASTRID:  Thank you, Jessica. I will remind you Sam that it is Greater Than Code, just to put that out there and I’m here with my great friend, Rein Henrichs.

REIN:  Thank you, Astrid, it’s my great pleasure to introduce Coraline Ehmke.

CORALINE:  Hey, everybody. For a long time listeners, you may be comfortable and used to a weekly show and we really want to be able to do weekly shows but unfortunately, with the level of support we’re getting from Patreon right now, that’s no longer possible. We’re announcing that we’re moving to a bi-weekly format. There are a lot of things we could do with extra funds and this can come from individual Patrons, as well as corporate sponsorships.

Beyond sustaining a weekly show, we’d like to focus on listener perks and swag for the people in Slack community who go above and beyond and are themselves, greater than code. We’ve also talked about doing conference appearances, which of course brings travel costs into the picture. If you are not yet supporting us in Patreon, I encourage you to do so at Patreon.com/GreaterThanCode and if you want to sustain the conversations, we also encourage you to talk to your employer about possibly sponsoring the show and we have information at GreaterThanCode.com/Sponsors.

JESSICA:  Also, can we say that it’s really exciting that we do have enough Patreon supporters to fully finance two episodes a month of this fantastic editing and transcription and website and social media, etcetera?

SAM:  Yay! That’s really wonderful, actually. One of the things that we really were hoping for when we started this show was to be able to continue to employ Mandy in doing the work that she does so well. I’m really glad that we can do that at least twice a month. I’m also here with Janelle Klein.

JANELLE:  There’s a lot of people on this call today and I am introducing Matt Stine whom I really excited to have here today. I met Matt a few years ago really just being a participant in No Fluff Just Stuff tour and he’s always been one of my favorite speakers just because he’s so anchored and pragmatism but so knowledgeable from software architecture standpoint and just being able to see so much scope and problems and patterns across the industry. He’s been one of the most fascinating people to listen to a talk to so I’m super excited to have Matt Stein with us here today. Welcome Matt.

MATT:  Very excited to be here. I love podcast composed entirely of chinchillas so I’m really excited to see what happens.

[Laughter]

CORALINE:  Jessica is making more chinchilla noises.

JANELLE:  I got a question for you Matt, as soon as we can calm the chinchillas down here but I was just wondering how did you originally get into software development. Where did all of your excitement about this come from?

MATT:  How did I originally get into software development? It depends on which starting point we come from. If we start with say, I was… what? Seven years old? I don’t know. My dad woke me up and brought me into the dining room and there was this Atari 800 connected to a TV, sitting on the table and said, “Hey, I got a computer.” I’m like, “Cool. What’s a computer? You mean like the thing on Star Trek?” He’s like, “Well, not quite,” but he showed me some stuff and then we’re typing commands and I’m like, “What was this thing we’re typing stuff into?”

He says it’s BASIC. I’m like, “Okay, well, what does BASIC do?” He threw a bunch of family computing magazines in my lap and said, “There’s programs in the back of that, type them in and see what they do,” and that’s where it really started. But it was mostly this informal romance back and forth with computers and games and gaming and didn’t really do a whole lot of software development, although I did poke around a little bit. Then it came time to go to college and I had to pick a major and I said, “I kind of do stuff with computers. That seems fine. Let’s do computer science.”

Then I found out what computer science was, which was a really jarring experience but I honestly don’t think I learned a whole lot about software development in studying computer science. I learned algorithms. I learned all sorts of interesting things about data structures and of course, all those things are pieces and are related to what we do but we had this class called software engineering and every class, every year gets a theoretically real customer, usually somebody from the community around the university that needs some software built. We’re supposed to learn software engineering by building the software for this customer, which sounds great until you realize that nobody’s ever actually taught you how to do that.

We had the dubious distinction of being the first class ever that this professor had that actually did not deliver the software so my first software project was a failure. I learned to fail from Day 1 and got out into the real world and actually learned software development and really from a bunch of people who’d come from other places that came to this little nonprofit that did not have any kind of discipline or whatsoever and we kind of invented everything that we did as we went along, which was both really good for me because I got to explore a lot of interesting ideas and do different things. But really bad for me when I went to my first job that actually had legacy structure in place. I said, “We need to do this.”

“No, you don’t get to do that here.”

“What do you mean?”

“We don’t do it that way here. We do this,” and I’m like, “Well, that stupid,” and we kind of grew in and learned from there. Now, like seven-ish years on the other side of that jarring transition from we’re making it all up as we’re going along to going to help really large companies that are figuring out that the big process of things that they’ve created is not helping them succeed and figuring out how to actually get them closer to. Really a lot of the early experiments or weird stuff that we’re making up as we went along back in the earlier part of my career says this weird kind of full circle feedback loop and I don’t even know how I got to this part of the story but we’re here now.

ASTRID:  Matt, I have a question. You talked about how when you picked computer science for your major that it was really jarring, kind of a slap in the face and not exactly what you were planning and that your first software engineering experience wasn’t that great so what motivated you to keep going?

MATT:  I was going to run out of scholarship money if I didn’t graduate so I wanted to keep going and people kept telling me that I was going to make a lot of money and I had no money so making a lot of money versus no money sounded pretty good. This was maybe a year before the dot-com boom exploded. The fact that you could theoretically walk out of school with a computer science degree and make serious cash and actually be able to not eat ramen noodles and stuff like that, that was real. I thought some of this sucks but I wasn’t really acquainted with the idea that work could actually be separated from toil because I watched my father toil for my whole life: work with something that he hated and I thought that that’s kind of what work was like the thing that you did to make money so that you could do the stuff that you really wanted to do. I’ve since obviously learned that there’s so much more to it than that.

I just thought that things were hard and you needed to continue going so the fact that it was maybe not what I expected or maybe not the most fun, I thought well, maybe this is just how things are. It took me a while to break out of that mold of people would say, “This is the way this is. This is the way we do this,” and to say, “You know what? There’s a lot of structure and assumptions that you built up there, what if things weren’t that way?” And people kind of look at you, “What do you mean by what if things weren’t that way?” This is what I do all the time now is just kind of try to find the underlying structural assumption that people have about the way something should be and say, “Let’s set aside all the challenges that we think we have. Let’s challenge that and see what happens.”

JESSICA:  You must be a consultant because people who are usually like that from people who actually work with them.

MATT:  People don’t like a lot of the things that I do.

CORALINE:  I don’t like the fact that you dinged ramen. I love ramen.

[Laughter]

CORALINE:  We don’t talk shit about ramen on this show.

MATT:  I like ramen. I just don’t like the stuff that I buy for 25 cents in the pack at the grocery store.

CORALINE:  MSG-flavored packets are so good.

MATT:  If that’s your thing, that’s great. Now, we did used to make this stuff that we called, ‘Oh, shit ramen,’ in high school with ramen noodles plus 18,000 spices and the whole goal was to see how fast you could make somebody sweat. That was entertaining and that was a great use of those packets. But I do like the fancy ramen that I can get down the street from the office. That stuff is really good.

CORALINE:  How long did it take you between your first job to becoming a consultant?

MATT:  I worked my first job for 11 and a half years.

JESSICA:  The one with non-profit or the —

CORALINE:  Yes, the nonprofit. The St Jude Children’s Research Hospital that’s in the bio on my website, for 11 and a half years. Then my next job, I worked nine months.

SAM:  Sounds more industry-appropriate.

MATT:  That was partly because I have a decent amount of need on a daily basis to have really good medical insurance for various family things that we have. This company’s medical insurance was almost as bad as not having any at all. I was paying ridiculous amounts of money for just almost nothing and I needed to find something else. VMWare happened to call me and say, “We’re looking to hire people who know Spring to go do consulting stuff and in the meantime, we’re going to give you this much,” and I said, “Let me do the math. That’s 37% more than I make right now. Yes, please,” and I became a consultant.

JANELLE:  Interesting to me because you seemed like one of those people that would generally have a hard time fitting inside of a box because you’re always challenging the status quo with everything. You fit well into that consultant thing where your job is to challenge everything. It seems like you would gravitate toward that, even outside of all these other kind of factors but maybe not. I don’t know. What do you think?

MATT:  It’s weird. I saw a consultant when I was working that original job and you saw people show up in suits with briefcases and telling you all kinds of things and language that you didn’t really understand. If you go back to the idea that we were the shop that started with seven people and eventually grew to 30 and we invented everything as we went along, it usually wasn’t based in, “Somebody told us to do this best practice because this would work and this is why,” to, “This thing hurts. Let’s figure out a way to make it not hurt. Okay, we fixed that. Now, this other thing hurts. Let’s figure out a way to make it not hurt,” so we kind of experimentally discover in the process that we had. It didn’t look like anything that anybody else did.

Then as we got bigger, people said, “Maybe we should figure out how other people do things because we’re getting big enough that we need to start acting like the big companies,” okay fine, so we brought in consultants. They said, “You’re doing everything wrong. You should do this,” and then we started trying to do that and everything got worse. My initial exposure to that was really negative and I kind of stiff arms, keep that away for a long period of time and it became the next obvious thing to do in my career that would help me, again make the money that I needed to support my family.

That nine-month job was the most important thing that I did to succeed as a consultant of anything I did leading up to that point because if I had only ever worked one place and I had never actually seen what went on outside of that artificial world that we had created for ourselves and saw, “This is how the big companies do it,” I would have been a really bad consultant because I would have been like oil and water as soon as I walked in to another customer and basically said, “You’re doing everything wrong,” and they’re like, “No, we’re not doing everything wrong,” and we would have never actually been able to communicate. I had some empathy for the people that I was now starting to work with as a consultant because I had experience the other side of that.

I had to evolve into the ability to do this work. There’s one thing that just challenge everything. It’s another thing to challenge in a way that people are receptive to that and that’s the thing that I’ve had to learn through doing over the last… I don’t know, I guess how long have I been doing the consulting thing? Maybe five and a half years?

REIN:  It’s really interesting to me that the market for consulting is so inefficient that those consultancy described having been pushed out of it.

JESSICA:  No doubt that implies that your objective in hiring a consultant is to do anything better. Seriously.

SAM:  Rather than doing something to do, something better?

JESSICA:  Yeah, I have an answer. Those consultants were bringing answers, right and you are bringing questions?

MATT:  Well, there’s model in this. My current view of what consulting feels like is very much driven by the way we approach things at Pivotal. So much of our practice is based in discovery and research and asking questions and trying to figure out what are the real problems that we’re trying to solve. Most of the consultants that I experienced before that were walking in with, “Here’s what you should do. I don’t even know who you are. I don’t know what your problems are. I don’t know what’s hurting you but you should do this.”

There’s another type of consultant, which was the consultant I’m friends with, who I would very often hire when I was in management for a period of time to say, “This is what I’ve been telling people and they won’t listen to me but if you say it, they’ll do it because you’re a consultant.” This actually as I found out goes on all over our industry right now, which is you need to be able to appeal to some of outside authority sometimes to get some change that you want to actually take place so you basically coach the consultant — who already agrees with — “This is exactly what I’ve been trying to say. This is what I want to happen.” They show up for a short term engagement, present this and it’s the same thing I’ve been saying for the last three years that nobody will listen to and he doesn’t go off script at all and all of a sudden we’re doing it.

CORALINE:  It’s like being a woman in tech.

REIN:  I’ll be honest with you, when I was a consultant one of the things I would do was survey the team, ask them what they think should be done and then pick a thing that they suggested and suggest it. The reason for that wasn’t so that I could take credit for their ideas, it’s so that I could take the blame if it failed and because they’d listen to me because they’re paying a lot of money.

MATT:  Yep.

CORALINE:  Matt, you mentioned empathy a little while back. How important is empathy in the work that you do.

MATT:  I think empathy is almost these center, the foundation of everything that I do because again, learning the hard way that trying to push change on people that aren’t at the same place that you are — I was having a conversation this morning about how in 2003, I went to an extreme programming conference and became infatuated with XP and then walked back into my organization and basically called a meeting of everybody and gave this manifesto and said, “This is what we’re going to do,” and people are like, “Yeah, that’s funny.”

The walk in with a big stick and swath everybody with that approach, doesn’t ever work, at least not in a positive way. You can make people do things if you coerce them enough but I wasn’t exactly in a position to do that. But the more of that I’m realizing that I have this place that I want to help people get to but they’re all starting from a different spot in their journey, either as an individual, as a team, as an organization and if I don’t tried to look at it from their perspective and stand in their shoes and understand the constraints that they feel like they have, the pressures that they feel like they have, it’s very difficult for me to communicate with that group, just trying to be them mentally, even emotionally because I walk into emotionally charged situations all the time.

One that happened a month or so ago at a large bank actually is still very vivid in my mind of two competing groups in the organization that have very different agendas that came to this meeting that had an agenda that was separate from either one of their agendas. Immediately, these two people — who obviously have some power — start co-opting the session and start trying to drive the agenda the direction they wanted to go, to the point where moments later, there’s 10 of us just standing there watching these two people arguing with one another about something that has nothing to do with what we were there to talk about and we’re like, should we stop them? What should we do here? We eventually just waited until the heat ran out in the room and said, “Let’s break for lunch.”

Then I walk back in and say, “We’re going to come up with a structure of this meeting that prevents what just happened, not to say that either of you are wrong but the rest of us didn’t really know what to do with ourselves and we’re not getting towards any of the goals that we said we were going to have on the agenda so let’s make a list of things that we’re not going to talk about and if they come up, you agree that if I say you can’t talk about that because that’s on the list of things that we’re not going to talk about, that you have to stop,” and people are really hesitant like, “Should I agree to this? I don’t really like this. Okay, we’ll do what Matt says.” The rest of the day was much better. In fact, most of the things that we said we were going to talk about actually never came up again and we got a lot of things done.

Sometimes you have to figure out, “There are some emotional political power play thing going on here that maybe has nothing to do with what we’re here but it’s infecting everything that we’re doing. Now, we have to figure out how to diffuse that,” but again if you walk in with a fixed agenda and you can’t be flexible and you can’t relate to where everybody in the room is coming from, it’s very hard to do that work.

Actually, what’s funny is that part of the thing that got my mind so much on this metaphor communication track recently was actually a result of that same meeting with that customer that I was talking about having to defuse all the crazy political driven emotions in the room. It’s pretty easy to segue into that conversation because in some ways, a lot of what I’m finding in a power struggle is people want to own the language because they feel like if they can own the language that’s used across the organization, they can control the conversation and drive it in the direction that they wanted to go, if that makes any sense.

REIN:  It just occurred to me that we’re going to spend the next 30 minutes recapitulating Wittgenstein.

MATT:  Really?

REIN:  Talking about language games and things like that.

MATT:  I’m not familiar with that.

REIN:  Wittgenstein was a philosopher, probably the most influential philosopher of modern times and one of his big concepts was that we all are playing a game with language and we each have our own language that we use and sometimes they overlap with other peoples and sometimes they don’t. We each have our own goals that we’re seeking when we play this game, with the language that we use and things like that.

MATT:  I’ve not heard that or articulated that way but it fits perfectly in with everything else that I’m thinking about right now so there’s probably a reason for that. That’s cool.

CORALINE:  There’s also the Sapir-Whorf Hypothesis that posits that the language that we use constrains our thinking. I think that what you’re describing could be considered weaponized language, where if you’re controlling the vocabulary of describing a problem, you are also constraining solutions to that problem to the space that you establish.

JESSICA:  Matt, can you give a concrete example of controlling language.

MATT:  Yeah. Right now the one that is happening everywhere that I go is microservices. Every company that I’ve worked with is now writing their definition of what a microservice is.

SAM:  — as definitions overlap.

MATT:  There’s some weird Venn diagram that we could draw that as differing amounts of overlap that eventually would become impossible to decipher. We’ll leave it at that but the interesting thing, going back to the weaponized language idea is that you find competing tribes within the organization that have their definition that they’ve come up with and they want their definition to win. Usually, it feels like it’s based in, “I want to establish constraints around people that I don’t necessarily have direct day-to-day control of so that I can control what they do because this is the organizational standard so therefore you have to do it this way.”

I have walked in to, again that same organization. I can think of maybe three or four different individuals who are with various different architect type titles, leadership titles that say, “I want microservices to have this bullet point list of characteristics and you have to do what’s on this list.” Part of that shouting match that we talked about was about differing opinions about, “Microservice should have this. No, it shouldn’t have this. No, this is crazy. What are you doing?”

JESSICA:  This reminds me a lot of Agile because the point of microservices that was each one could have different characteristics.

MATT:  Yeah, that’s not how the Fortune 100 conversation around microservices is going right now. It’s everybody is building a PowerPoint deck with, “Here’s what a microservices and here’s the characteristics that it must have.” Now, what’s really bizarre and happening that kind of sucks is that deck is now being broadcast to a huge organization of people who don’t have any understanding of what they’re paying told to do and they’re just naively going through and checking off the bullet points and saying, “Our service does this, it does this, it does this. Okay, we’ve built a microservice,” and no freaking clue why they have built one, what they’re supposed to be getting out of it, what the value is but they were told they’re supposed to build microservices so therefore, they built them.

Another organization, I’m giving a huge talk and there’s a question and answer session, somebody stands up and says, “We’ve got fifty microservices in our application and new ones are appearing every day and this really hurts. What should we do?” I said, “You should probably build less microservice,” and people laughed and it went back and forth a little bit. Somebody comes up to me afterwards, the sponsor of this particular event and says, “Let me tell you the back story to that question that you’ve got. His organization has been incentivized by their manager to build as many microservices as they can so that he can basically demonstrate to the rest of the org how awesome their little sub-org is at being on with the microservices initiative and all the stuff that they’re doing and here’s all these metrics that we have to demonstrate that fact,” but it’s leading the people who are actually living that life to experience ridiculous amounts of pain.

Janelle and I have been talking about lemmings a lot lately and we have all these lemmings and they’re marching off the cliff dutifully because they know that’s what they’re supposed to do but they fall to their death. They don’t know why because that’s what lemmings do. Maybe we’re doing it consciously and I just don’t know it but I feels like I want to believe that it’s unconsciously that we’re creating these legions of lemmings in software development in these large organizations that are going and doing all this work.

They don’t know why they’re doing it but they’re told that if they just do it, it’s going to solve all of their problems. It ends up creating new problems — big surprise to the group of people talking on this podcast — but very often the answer is, “You’re just not doing it right. You must not be microservicing correctly because microservices solve all your problems and so let’s try to microservice even more.”

Now, I this person who’s been hesitate to say, thought leader in this particular area, people pass around my little 50-page O’Reilly book like it’s the Bible or something and say, “You should do everything that’s in here,” and now I’m going around so you do know all that stuff I said about doing in all these microservices, I don’t mean this. Don’t do what you’re doing right now. This isn’t what I said and they’re like, “But you’re the microservices guy.” I’m like, “No, I’m not. I’m the, let’s build software and solve problems guy and microservice is a tool in my belt but no. Stop. What you’re doing is going to hurt. It’s not going to end well.”

REIN:  Your book isn’t just one page that says, “Microservices. Yes, more of those please?”

MATT:  I think that’s what people have translated it to.

REIN:  It’s interesting to me. We could probably have a whole conversation on the choice of count of microservices as a proxy for successful implementation of the microservices or whatever.

JESSICA:  It’s like the line of code metrics.

CORALINE:  Yes, Jessica.

[Laughter]

JANELLE:  It’s interesting to me too because there’s a whole control dynamic here going on with internal fiefdoms competing against one another and then trying to come up with some metrics that gave them control to influence another organization and then using language tactics and things like this to own vocabulary. There’s a whole entire empire building thing going on. One of the things I see happening on the engineering floor is it’s so difficult and takes so much energy to fight the momentum at that organizational empire level that people just decided not to care because it’s easier. At some point it is like, “Whatever, we’re all going to walk off the cliff. It’s fine by me,” and like genuinely choosing not to care anymore as a coping strategy.

SAM:  If we can, I’d like to go back to something you said a little bit earlier, Matt about how there’s these different competing definitions of microservices and architects are putting together PowerPoint slides and saying, “These are the characteristics that your microservice must have in order to be considered a microservice.” I’m as cynical about corporate power structures as the next person but I really want to give people the benefit of the doubt and I wonder how much of that comes from the architect’s previous painful experiences of like, “I tried this and it sucked and I’m trying to save you from that by just telling you the answer,” despite that strategy perhaps not being the most successful one for actually getting people to do what they should be doing. What do you think about that?

MATT:  I think that most of the time these efforts come out of a place of good intentions like what you just described like I’ve been down Road X, I have the scars to prove it and I want to help you not feel that same pain and that part is good. I’ll probably butcher the cliché but that’s fine of you can’t solve the problems that you have with the techniques that got you here. The various forms of the thing being said but it’s like, “This thing hurts. I don’t want people to repeat that so I’m going to tell people how not to hurt themselves by following the exact same process that I followed to hurt myself in the first place.”

One of the biggest examples I had of this — I only deal with large organizations right now because that’s who we try to sell to — they sent me this 150-page Word document that describes their microservices strategy for the organization. As painful as it was to read it, I read it. It was a mishmash of cargo-culted paragraphs from blog posts from Martin Fowler and other people that have authority. Eric Evans was in there and all kinds of things, then it describes this reference architecture that as I talk to people in the organization, I found out what they basically did was they took the thing they already had and rename all of the things to match the terms that are floating around in the industry right now and change the technical stack to be basically with our Spring Cloud Foundry stuff with some other things thrown in there.

I said, “Basically what you’ve done is you’ve created what you already had with new toys and you went to great lengths and pain to do it. The whole point in my mind of going down this road is to free you from the very constraints that you’re actually trying to reimpose upon yourselves,” and they’re like, “Yeah, but we have to have these constraints.” I’m like, “Well, let’s look at that from two different directions. One, we can challenge whether you have to have those constraints or not but that’s a hard conversation. We don’t have to have that one right now. Let’s have an easier conversation. You have to have these constraints. Why do you need to change anything then? because you’re actually making it harder for you to enforce these constraints with this new set of disciplines and techniques and technologies than what you already had, because the things that you already have are actually designed to enforce those constraints and you’re now trying to take something that’s designed to free from those constraints and use it to enforce these constraints.”

They’re like, “We’ve never really looked at it that way before.”

SAM:  And they’re using tools that don’t have those constraints.

MATT:  Right and so I was like, “How do I do control X with microservices technology?” And they’re like, “We don’t.” I’m like, “What do you mean? How do you not do control X? Have to do control X.”

“What is the goal of control X?”

“Well, to prevent those –“

JESSICA:  Transactions.

MATT:  — other things. We’ll prevent that thing from this –” Oh, let’s not even talk about transactions.

[Laughter]

MATT:  I just don’t want to go there. That’s just such a bad, bad place but everybody’s going there so we should probably go there too.

[Laughter]

JESSICA:  And that is one of the constraints that people are used to from a relational database like Oracle. But when you go to microservices, you don’t get that.

MATT:  That’s probably actually okay in a huge percentage of circumstances but because we made transactions so easy, we made everything transactional. Now, it’s hard for us to even conceive of a world that has things that aren’t transactional so when I say, “Think about the process as separated from the software. Is that process inherently transactional by meaning ACID transactions? Is it truly atomic, which is usually we don’t have to go beyond atomic. But is it truly atomic?” They’re like, “Actually, this thing happens one day and this other thing happens another day in the real world.”

I’m like, “Then why are you trying to make software do anything but that and I’m not even trying to tell you to have it spend a day. I’m trying to tell you have it spend seconds and you’re resisting seconds but the actual thing that happens in the real world is taking multiple hours and we get tongue tied because we’re walking into a set of fundamental assumptions and were saying, poke that one and kick that one out and now reformulate the world.” All of a sudden, not only is it more freeing but it’s also more scary because we haven’t been there before and this constraint, while it’s limiting, is also feels like protection.

JESSICA:  Like it’s comfortable?

MATT:  Yeah. Going back to the original, I want to define the language conversation, it’s because we’re trying to find a structure. One of the things that Janelle throw this book at me metaphorically and I’m digging through this bit about structural isomorphisms between different things. The one that they’ve been beating on now for a while is argument is war and it points out all the language that we use when we’re talking about arguments. That’s all based in talking about war.

They extrapolate on that a little bit so I started thinking about how does that play out in conversations that I’m having. The thing that I stick with is people come with the structure that they want and then they tried to create a mapping from the popular conversational metaphors to the structure that they want, like why do I care so much about owning microservices and bounded context and all of these things as terms. If I can own those terms, I can map the structure that I want and I can appeal to outside authority at the same time. I can get power from the words but then use the power and inherent in the words to actually get this other thing that I want.

ASTRID:  What you’re saying, Matt sounds like something that I heard recently that was about interviewing. It was not about technology at all. One person was talking about like when you got and interview somebody, you have a way that you try to make them feel so that you can get what you want out of the interview. His version of it was trying to make people feel at home so he would try to be welcoming and eat whatever they gave him or drink whatever they gave him. He was saying there’s another interviewer, I think it was Jorge Ramos who’s interview style is war because he is used to being a person who learned journalism in Mexico where the press was marginalized and suppressed. He’s used to having to poke at the bear to get the answers that he wants so his interview style is much more aggressive.

Maybe it’s related to what you’re saying because if you’re in an organization, where in your position, you have to be aggressive, then when you’re talking with your own staff, you’re going to be like that, whether you realize it or not and be less open to their suggestions as opposed to somebody who might be much more like collaborative in trying to gather all of the information. You’re not going to notice that you’re not talking the same language.

MATT:  Yeah, so the extensions of that — and I think that’s right on — is that I, as an observer without that context of why I’m behaving the way I’m behaving, sees that person being aggressive or sees that person being welcoming and saying, “That person behaves this way and that person is successful, therefore if I behave that way, then I will also be successful and I divorce the practice from the context.” That same aggressive behavior that works in that context taken into a context where aggressive behavior is viewed as pathological is going to blow up in your face. That’s an obvious example. But the less obvious example is if I do what Netflix did with their software, I will be successful in software but we’re forgetting the very important point that I am not Netflix.

SAM:  My problem is not their problem.

MATT:  Exactly and I’m not to say that there are no other organizations that can use the exact same set of practices and techniques and be successful. It just means that not necessarily you. It could be you but may not be you so it’s probably better to figure out where we are and try to get to where we need to go.

SAM:  As kind of a follow up to my previous question about people who have come up with their own language around defining the constraints that they want to impose on everybody else, I’m wondering how you can facilitate a conversation between people who have different words and different idioms that they’re using to try to impose these things and if you can get those people to come to some common agreement and how do you do that?

MATT:  I probably haven’t done that exactly the way you posed the question and that would actually be interesting. You’ve got a couple different scenarios. You’ve got two people showing up with different words for the same thing. I usually have, maybe the inverse of that which is people are using the same word to mean different things.

SAM:  That never happens in software.

MATT:  Right, it’s everywhere. One of the things that I’m using, I think more as a trick than it is a technique right now is to double down on the fact that everybody seems to be newly obsessed with Eric Evans and Domain Driven Design. I start talking about ubiquitous language and I start saying that, “You’re using a word to mean this and you’re using the same word to mean something different and that’s leading you to frustration.” Eric Evans talked about this problem and I expound on the whole idea of ubiquitous language in a nutshell being that when we use the same words, we mean the same things.

Sometimes, I’ll even go often to talking about, “And that’s what a bounded context is. It’s a domain model that has ubiquitous language,” but depends on how excited that particular group is about that term or not because most of the time it’s a language that they picked out of the industry conversation. We talked about microservice. I’ve mentioned bounded context as another term. There’s a lots of these there floating around right now so they’ll grab one of those terms that people are saying is, “This is a good thing. This is something that you should strive for and they’ll define it to mean what they want it to be.”

I’ll say, “You know what? That thing that you want, that’s valuable. That’s a good thing and this other thing that you want, that’s different is also valuable and a good thing. Let’s name those things.” You don’t get to use microservice as the word for that thing. You need to call it something else.

I kind of go back and forth with them a little bit about if you find things that are valuable, you should make up a language that makes sense to you so that other people in the organization — when they encounter these terms — they’re not confused because I read this book that said that word meant this or I read this blog post that said this word meant something else. You’ve defined within your organizational lexicon that this term means this thing that you value as an organization and that helps diffuse things a little bit because I was like, “Oh, cool. We get to invent new words. That sounds like fun.” That helps a little bit. It helps people to feel like the ideas that their brain to the conversation are in fact valuable ideas, instead of being told, “You’re wrong. That’s not what a microservice is,” because I’ve tried that strategy and that strategy doesn’t work very well. They feel like, “Oh, my thing is good. My thing just needs a name and the name that I’m using is confusing because it’s defined elsewhere,” and I understand that. That feels right.

Then we start to get into a useful language defining conversation that feels a little bit like modeling and who doesn’t like modeling a problem space and giving names to things? Then you’ll say, “You know what? We’re creating ubiquitous language right now, at least amongst the group in this room,” and then now we can use that to expand and educate other people in the organization, instead of confusing them by redefining all these words that they’re either already using or they’re encountering in a conference talk or a magazine article or something else.

CORALINE:  There’s a recent Douglas Hofstadter book that talks about metaphors and similes as the fuel and fire of thinking. One of the things that’s pointed out in the book is the supremeness of metaphors. I think we’re particularly susceptible to this in software development because we are not really involved in neologism so much as repurposing existing metaphors. We use smoke tests, we use server, we use client, we use composition, we use all these words that have barred from different disciplines and I think it’s only natural that, as human beings we conceive of these terms differently. We mapped the metaphors differently. I think neologisms is a really interesting way to frame a solution to that problem.

JESSICA:  Neologism. Does that mean making up new words?

CORALINE:  Yes.

JESSICA:  Did you make that word up?

CORALINE:  No. Yes, I invented that word.

REIN:  Matt, this idea that you’re talking about of universal language, I just want to mention is exactly the concept of language games by Wittgenstein. It is building a shared group of concepts that you use to describe your shared activity in the real world.

MATT:  Yeah. The interesting thing, when you’re going back to that metaphors we live by a book, the premise of that book and I’m only about a third of the way through it at this point but I already feel like I’ve got probably a few months’ worth of things to think about just from reading that third of the book, is that we kind of have these metaphors that are so ingrained in the culture that we use them without realizing that they’re metaphors. The argument that it is war is one that’s easier to see but there was one that was really good. Janelle, you should be able to jog my memory on this, maybe.

There was the whole structure in there about talking about things that aren’t containers and calling them containers because he would say that a person, for example, is in love. If you’re in something, you’re inside of a container so the metaphor is actually that love is a container. He talked about that a little bit and I can’t remember half the stuff he said. It was really good stuff but we walk around communicating in these metaphors all the time and he makes this statement that really there is no such thing as non-metaphorical conversation. At least what I take away from it is that you can actually walk everything back to a metaphor and it feels like there’s this concept that eventually you should get to things that are atomic and there’s a whole chapter in there that challenges the idea that there’s actually anything that’s atomic from an idea perspective, that you can always take something and break it down even further.

CORALINE:  Hofstadter talks about that as well. In a talk that I gave recently which is called, ‘Metaphors Are Similes. Similes Are Like Metaphors,’ I talked about how the standard scientific method is about seeking the atomic components, about solving small problems and composing solutions to small problems into a larger solution. Then we have something like category theory, which says the small pieces don’t matter. Let’s look at things from an even higher perspective and find the similarities that way and compose a problem-solution pair that is about shared characteristics, rather than differences.

REIN:  We’re talking about how to bridge two different people sort of universes of language so they can share an understanding of something and we’re talking about metaphors and their relationship to some truth. Metaphors don’t actually describe the thing. If they perfectly describe the thing, they wouldn’t be metaphor. Metaphors are leaky analogies or are very leaky abstractions. Wittgenstein has another concept called Wittgenstein’s Ladder which might be more familiar to some people as lies to children, which is where we attempt to bridge a differential in understanding between two people by saying something that is not true but is more true than their current understanding. If you do that enough, you eventually bridge that gap with the caveat that you then have to throw away the bridge that you’ve built because it’s no longer hopeful, because it’s a lie.

MATT:  That’s simultaneously fascinating and terrifying.

SAM:  Don’t take off in the middle of that process.

REIN:  Strong agree.

JESSICA:  If you give people a whole list of check boxes for what it’s a microservice for instance, some of those are like with those equality, the [inaudible] resilience or [inaudible] breaking. Some of those are going to be within reach and useful now but some of them are not.

MATT:  The one that I think is both the most misunderstood and also the most dangerous is this database per service concept. There’s this idea that I think’s a very valid one that if you have a bounded context and you’ve got this domain model that has a boundary put around it that controls what comes in and what goes out so that you can protect the integrity of the language you use within that circle. One of the things that we say is you can’t have a shared database across multiple-bounded contexts because then I can actually not go through your front door to engage with you. I can go through the back door and talk directly to your data and make it do the things that I want to do or get the information that you say I can’t have. That’s important and valuable and it’s a principle that I think is interesting.

What we’ve done is we’ve taken that and we have turned it into a bullet point on a slide that says microservice should have their own database. Or even worse, every microservice should have its own database. Notice the difference there?

SAM:  Now the implication is microservice should have a database.

MATT:  Right.

JESSICA:  Whether they need one or not?

MATT:  Yes. Exactly.

[Laughter]

MATT:  And so, I walked into an architecture’s conversation. They’re showing me they’re like, “Every single microservice had a database,” and I said, “Why does this one have a database?” They’re like, “Because it’s a microservice.” Like, “Yeah but why does that microservice have a database?” They’re like, “Because every microservice has to have a database. That’s what makes it a microservice,” and these were genuinely confused people. They had been taught this and they were doing what they were told. It’s worse than cargo culting. I don’t know what it is, like cargo culting, “We adopt something, we don’t know why we adopt it. In this world, we’re doing something we were told to do and we don’t know why we were told to do it but it’s the rules because it was in the slide deck that said this is how you microservice and we were told we have to microservice.”

There are these things that we put on the list that are based in some truth and because we want to simplify it, we want to get people closer to this thing that we want people to adopt in a way of building software, the simplification becomes actually adopted as the truth, which is the thing that I thought was so scary about as you said is we built this bridge and then it’s appropriate to throw it away at some point but not only do we not throw it away, we actually double down on it.

REIN:  Yeah, you sort of engrave it into the structure of your organization and say, “You have to understand this bridge. This bridge is now part of our organization,” when in fact the bridge was only there to get everyone to a shared place of understanding and past that point is counterproductive.

SAM:  But the bridge was given to us by an authority and that short circuits a lot of stuff in our brains.

REIN:  I mean, we can get really mad in here. We can talk about how do you create knowledge in another person’s brain. We’ve talked about through rote just by telling them the thing and how that often isn’t very effective because they don’t really internalize it. We can do it by building a bridge through metaphor and through analogy. I think, Jess you were talking about earlier, sometimes it’s important to let people fail because sometimes the best way to gain your knowledge is through experience.

JANELLE:  I feel like the other major theme here is that everything is this solution-centric conversation and everyone gets caught up in this argument of what the solution is supposed to be and everybody’s forgetting about what problem it is we’re trying to solve to begin with that at the end of the day, getting back to the pain, getting back to the problem that we’re trying to solve is the thing that I think anchors everybody back to that same goal and purpose of why we’re here to begin with. It’s just so easy to get lost in all the solutioning that we end up just forgetting that.

SAM:  I think that as technical people, we also have an obvious bias towards solutions and shiny new toys, which does not help us in any way in this conversation.

CORALINE:  I know, let’s replace our government with software. Let’s all be technocrats. Every constraint on a system is a scar from a previous experience.

MATT:  There was an interesting conversation that we had on Twitter, I guess two days ago and it was a broken conversation for me because I started it as a flight was getting ready to take off and then I’ve continued on in-flight Wi-Fi poorly and then I started again while I was trying to get out of the airport — this is how committed I was to this conversation — and I forget exactly what the trigger was but we were talking about this transition from this thing that Simon Brown calls a modular monolith, all the way over to the microservices as an evolutionary thing and why that’s a good way to go.

Adrian Cockcroft pipes in and says, “In Netflix, we spent like X number of months –” or years, I can’t remember it was, “– struggling and trying to build a modular monolith and we have initially eject it and went to microservices.” And I asked the question to follow up and say, “I bet you learned a lot through that struggle. Do you think –?”

SAM:  Are you assuming it was a struggle?

MATT:  Well, he said it was a struggle. I said, “So you had a struggle there. I bet you learned a lot, do you think that you would have been as successful had you not had the struggle? Had you just gone straight to microservices on Day 1?” He responded. “No, we developed and anti-architecture of painful things to stop doing,” was I think his exact quote. That really resonated with me because the thing that I felt going through my mind in the earlier part of the conversation, maybe a couple minutes ago, was solutions versus what problem we’re trying to solve. It feels like an economic problem. If we could just get the right solution on Day 1 and just implement it, that should be cheaper than struggling through the figuring out of the problems stuff because that takes time and effort and that time is not free.

But if you pick the solution on Day 1, assuming that it’s going to be correct, it looks like, “We didn’t go through all that stuff, all that discovery process, all that figuring out the problem. We just have the solution so we saved all that money,” and then it blows up in our face later on the project and we end up paying for that and probably paying beyond what we would have originally paid, had we just struggled through the original discovery process.

SAM:  It will just blow up.

CORALINE:  That’s why I like to say that monolith is sort of an important part of the evolution on any software system because creating a monolith — the system — lets you define the domain and you have no idea what services you need until you thought the pain of having everything be tangled.

MATT:  Right. Exactly.

SAM:  And having the monolith gives you the ability to move things around without crossing a service boundaries that are significantly more expensive than module boundaries.

CORALINE:  Yeah, you don’t even know what those service boundaries are when you’re just setting out to solve the problem because you don’t have that perspective yet.

JESSICA:  Matt, you mentioned that you tried to put in the solution to all the problems that you’re going to have at the beginning and then it blows up. How does it blow up?

MATT:  By blowing up meaning that we adapt a solution without going through this process of discovering and finding where the pain points actually are, where the boundaries ought to be so we get a completely different set of — going back to the idea of accidental versus essential complexity — accidental pain versus essential pain. There’s pain that’s inherent in the problem that we’re trying to solve and we adopt a solution that doesn’t address that pain so we now get different pain, which is the pain inflicted by the solution on the things that the problem didn’t actually inflict upon us.

This is manifested in a lot of clients that I’ve worked with where they set out and they figured out, “We’re going to draw all these microservices on the whiteboard and these are good so we’re going to build that,” and then six months into that project or a year into that project, they come back and I say, “Show me the architecture,” and it’s not the same architecture. Usually, they have less services than they had before and say, “What happened to this?”

“Those services made life worse so we backed them back into monoliths,” which one of the very first things that I did before microservices [inaudible] in the term that [inaudible] around, I was working in the world of OSGi and we have built this whole architecture based on different OSGi modules. We did a very bad job of defining our modules and OSGi made our life a living hell. One weekend I said, “Screw it. I’m backing OSGi out and I’m recreating a single codebase.” The pain of the modularization that we needed was still there but all the pain of the stuff that we had created artificially went away.

I am well-acquainted with a bunch of microservices and then back it back into a monolith. It’s a painful expensive process to go through so myself and a couple other folks have theorized from different directions, maybe we should defer the creation of the distributed system. I don’t want to say things like to the last responsible moment because people have used that in weird and crazy ways but defer it until something obviously hurts and then figure out is separating along a boundary of where this pain point is, is that going to potentially make the problem better? Do that one thing. Do that one thing and limit the expense to attacking that one pain point, which should be a smaller experiment than we’ve got 25 microservices and we need to go back to 12 or we’ve got 12 and we’ve got to 25. Then experiment.

Is this better? If it