Jonathan Crossland, software architect, author, and business owner, joins host Jeff Doolittle for a conversation about the AMMERSE framework of design principles. They start by discussing the agile manifesto as a statement of values, and Jonathan shares his perspective based on his experience as a software developer and business owner. They then explore the three layers of the AMMERSE framework and how they help business and engineering leaders to align their values, thereby improving their ability to collaborate and reach common goals.
Show Notes
From the Show
- Guest twitter: @jcrossland
- https://ammerse.org
- An abstraction language for aligning Individual and organizational values
- Manifesto for Agile Software Development
- Test-driven development
- CI/CD
Computer Society Digital Library
- Values@Runtime: An Adaptive Framework for Operationalising Values
- Core Values
- Organizational Values and Agile Methods Deployment
- Towards Integrating Human Values into Software
- How Computer Systems Embody Values
- Engineering Values: From Architecture Games to Agile Requirements
- Design Thinking in Practice
From SE Radio
- 520: John Ousterhout on A Philosophy of Software Design
- 518: Karl Wiegers on Software Engineering Lessons
- 470: L. Peter Deutsch on the Fallacies of Distributed Computing
- 407 – Juval Löwy on Righting Software
- 359 – Engineering Maturity with Jean-Denis Greze)
- 331 – Kevin Goldsmith on Architecture and Organizational Design
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Jeff Doolittle 00:00:18 Welcome to Software Engineering Radio. I’m your host, Jeff Doolittle. I’m excited to invite Jonathan Crossland as our guest to the show today. Jonathan is a software architect, computer programmer, author, and business owner. He’s the author of multiple books, including Beginning VB.NET and Professional VB.NET. He is currently working on a four-volume set called The Programmer’s Handbook. Jonathan is also the creator of the† AMMERSE Framework of Design Principles, a philosophy and set of heuristic principles for designing software solutions, which is the topic of our show today. Jonathan, welcome to the show.
Jonathan Crossland 00:00:54 Hi, Jeff. Thanks for inviting me. Yeah.
Jeff Doolittle 00:00:56 Absolutely. So I mentioned in the top of the show here the idea of the, and I think I said it incorrectly, so let me correct myself. The AMMERSE framework, which is spelled A-M-M-E-R-S-E, AMMERSE, and that’s what we’re here to talk about today. So give our listeners a bit of a history and background on what this framework is, sort of how it came to you and what it’s for.
Jonathan Crossland 00:01:19 Okay. Thanks, Jeff. So AMMERSE is a set of values. There are seven values, it’s a mnemonic, and we’ll get into those values. The way it came about is within the normal dealings and roles that you fulfill within software development, talking to various stakeholders and getting to know different people, you soon realize there’s a disconnect. There’s a disconnect in terminology, collaboration tools, as in technology terms, buzzwords, processes, practices, there are bounding, right everywhere. And it’s all to solve this, this collaboration problem. And so at that time, I thought perhaps there’s something underneath all of this, right? Perhaps it’s the software engineer in me trying to see what underpins things. So AMMERSE is really the values, the seven values that I came up with, that I thought at the time, and this is 20 years ago, that I thought would be underpinning everything that we collaborated on in these software roles and all the people.
Jeff Doolittle 00:02:20 So how did you arrive at seven?
Jonathan Crossland 00:02:23 Okay, so elimination, right? So , generalization, abstraction, all the usual software things that we’ve come to know, looking at personal values like trust and openness and mindfulness and being present and all these kinds of things, and realizing, wow, that’s personal. Looking at organizational values and seeing that, well, this is virtue signaling, this doesn’t really mean anything, right? They come up with words like vigilance and everyone in the organization wonders, well, what’s that about? Like how do I be vigilant? Vigilant about what, right? What are we discussing here? So, when you look at those two angles to personal values, it’s a huge list, right? Hundreds and hundreds of things. And the process came about by just saying, well, is this like this one? Is this in the same category? These are shapes? So do these shapes belong together? Are they shapes? Is it an abstraction of shape? What is it? So eventually just boiled it down. Boiled it down, that’s reachable. Okay, so what things are reachable? Am I an approachable person? Okay, so that falls into that category, environmental sustainability, that falls there quite neatly. What else falls there? And I wouldn’t say I came up with the seven as they are now immediately, but as very close just by natural selection, right? Just sort of pulling things apart and grouping them.
Jeff Doolittle 00:03:52 Okay, so you mentioned values, which I think is interesting because a lot of software companies, as they think about process and they think about values, they go back to the Agile Manifesto, which essentially is a statement of values. It’s a statement of, we value these things over these other things. And I believe, if I’m recalling correctly, there’s four different things. We value people and interactions over processes, for example. So I’m curious, how much that influenced you and sort of where this exploration of values both maybe dovetails with that concept, but also maybe differs in some ways as well.
Jonathan Crossland 00:04:28 Right. So AMMERSE was kind of 1998, 1999 was the first thought that popped into my head. Every other month when I saw the Agile Manifesto came out, I thought, well, do they value what I value? And it largely aligned. And I thought, well, that’s good because where I’m sitting right now, it’s not the same kind of values that I’m thinking we should have. And so the Agile Manifesto was kind of along the correct road, right? It was to me at the time anyway, it was something to get behind because it understood some of the values. But at that time, I was still looking at it and saying, well, is that an axiom? Is that truth? Is that universal? Can I generalize this even more? But I think I didn’t really click on it immediately. It was really an evolution of over the years where the axiology of everything came more to the front.
Jonathan Crossland 00:05:27 And I really started looking at the atoms of value, right? So the categorization, the ontological approach, and then looking at the Agile Manifesto and saying, well, in this situation, I agree with them. In this situation, perhaps not. Did they mean that? And I think naturally people have put a lot more into the Agile Manifesto that perhaps they originally put in, and things evolve, and people understand it differently. 10 years later they understand it even better or maybe in a different way. And so I would say that it aided my philosophy because I thought it was about values. But even till today, I think that the Agile Manifesto is specialization in the context of people thinking about software and their everyday job, right? What they’re doing and the people that are around them, where I feel that I zoomed out a lot more. I zoomed out a lot more and try to get the bigger picture. So, I think AMMERSE is underneath AMMERSE those values, the seven values. You can use them to describe the Agile Manifesto. Because if you favor people first, then what is it? Well, you’re an approachable person, right? So you want to be approachable, you want people to reach you. And so there’s various behaviors that come about from that value. So I think it’s, to make it a shorter answer, I would say it’s very much in line, but it’s underneath it all, I think.
Jeff Doolittle 00:06:55 Yeah, and that’s interesting too. You talked about actually thinking through the values of the Agile Manifesto as opposed to just adopting them wholesale. And I think that’s been a challenge for many organizations as well, at least in my experience. So you mentioned a moment ago the idea of virtue signaling, which I think is really interesting. When we talk about the idea of values, maybe you can speak to our listeners a little bit about your experience of why values actually matter. I wonder if people may struggle, like, I think fundamentally we get that some sort of values drive us in this kind of thing, but often it may seem to your point that maybe companies adopt values because they think they should, but maybe they don’t operate according to them, or they don’t really use them for anything that’s effective. So can you speak to some of the reasons why in your experience it’s important to consider our values and how we operate according to them?
Jonathan Crossland 00:07:49 Sure, sure. So when you think about values, there’s sort of two lines of thought here. Some people get immediately taken aback by it because it’s too personal or it’s perhaps too abstract, right? It’s trust. We understand trust, we understand integrity. But what does it mean in business? Well, it’s ethical, right? We’re not talking about ethics right now, we’re talking about. And so I think the discussion can very quickly get into a very personal area where people really don’t feel comfortable discussing every nuance about how open they may be. For example, who’s going to say, well, I’m not honest, you can’t trust me, . So, I think there’s that personal level at first, and then there’s peer pressure, the organizational, the industrial psychologists, the sort of industrial complex of broadcasting your values. Who are you as a business, your why, your this, your that, and so on.
Jonathan Crossland 00:08:51 And then organizations have to sit down and say, well, is this something I want to do? Is it kooky? Am I talking about spirituality and ethics now? What are values? And if it means something to the business, what kind of words can I use that describe us? And I think people get lost in both of those areas. It’s very, very tough to sit down and say, my business isÖ, we feel that these values are more important. So what about that other value or that other one, oh, that’s also important. It’s really, really difficult because they’re all important. And I think there’s those two starting points, but I think it gets very complicated straight away. When you bring everyone in, now you’ve got different individuals with their value set not being able to fully describe their values, all melting together to form the culture of the organization.
Jonathan Crossland 00:09:50 So I think values, to answer your first question, I think values are so fundamental, but I think it’s flawed because the language is difficult. The topic is tough, it’s very complicated, and nobody really understands the pragmatism or it’s not tangible. That’s the first side, right? The second side is I think people get caught up in the direction of their company, and perhaps one director or an owner may say, well I prefer openness. And then the whole company will be about openness, or they’ll pick something and go along those lines. But I don’t think it truly dives into the organization. I think that’s where everyone struggles. How do we turn a culture around? How do we influence a culture? Can we influence a culture? Should we influence? So I think it’s a very broad topic, and I think it’s so complicated, but mainly those two first points, I think stop people from really identifying truth because it’s confusing. So AMMERSE is about taking seven values that are not personal, they’re about business, but they have a personal category that there is something personal about them that you can identify with, but not feel like you’re giving away your value, so to speak. And you can all gather around a certain pillar, like reachable, solvable, extensible, and you can sort of reach around it and say, well, I’m more extensible than I am minimal. And so, but not in a personal way.
Jeff Doolittle 00:11:25 Interesting. And we’ll dive more into the specifics of the values as we continue here. So one thing you alluded to there, which I think is fascinating is the distinction. You didn’t call it this, but I’ll summarize it as the distinction between stated values and actual values. So share a little bit about how you’ve applied, the AMMERSE framework and how it can help sort of maybe resolve the possible tension between aligning stated values with actual values.
Jonathan Crossland 00:11:54 Okay. So you can very quickly see if somebody says, well, right, we’ve got a support team and we want the phone to be picked up within three rings, and we want to deal with that customer in a friendly way and immediately solve their problem. If they can’t, I want it to be traveling to tier two and the phone must be picked up in three rings. If that is your goal, if that’s what you’re trying to achieve, if that’s where your vision is for your company, for your support system, you obviously put the customer first, right? You are obviously thinking about the customer, you’re obviously thinking about your impression that you give your customer and you’re thinking of helping them. So if you hire 19, 20-year-olds fresh out of Uni or college or whatever, they don’t have a job. They don’t want to work.
Jonathan Crossland 00:12:43 It’s their first entry point. They think they’re going to become programmers one day. So everyone’s told them support, you’ve got to get into support. It’s good maybe data capture, but you’ll get in there somewhere and they’re not feeling it, they’re not understanding this, their values are definitely not aligned with that kind of role. So I think it’s quite easy in that kind of example to understand the difference between a youngster coming into business for the first time, eager to gain knowledge, eager to do complex things or learn and adapt. But perhaps customer service is not the first line of thought for him. Possibly, it could be, it could be their hidden talent and they really want to get in there. But the point is, does the value align with the role and the type of work and what the organization is promoting? So if either one of those pillars are not aligned, you’re not going to fulfill what you’re trying to achieve there. And I think often the token value, right, is saying that you want to be customer focused, but not understanding the culture and the people that you are employing to place them into these various roles means that it becomes something that’s not enacted,
Jeff Doolittle 00:13:56 Right, or the training or the investment that it takes to take people to that level.
Jonathan Crossland 00:14:01 To that level, correct. There is a gap. And the gap is what’s important. And AMMERSE, it’s different layers of a toolbox, right? Different things for different situations. But one of them is, it’s a language that you can look at, it’s a mindset. You’ve got these seven values and you can look at the gaps. Do I have a gap in training this person? They need to be more reachable. This is the value that we need to instill. What are the lessons we can employ to teach reachability?
Jeff Doolittle 00:14:31 And speaking of reachability, let’s start diving into the values of AMMERSE. And since this is a podcast and our listeners are only able to hear us and can’t see, I just want to describe briefly that first off, we’ll be going through these values, not in their order, in the word AMMERSE. Thereís actually multiple levels. And, I imagine that you can unpack for us a little bit more as we continue through the episode on why these levels exist and what it means to move through these levels. So imagine a road, and at the top we’re going to start with a value that you just referred to called Reachability, which is at level one. And we’ll continue down through the seven values and describe what it means to move through the levels and a bit about how these values tend to interrelate with one another. So let’s first start with Reachability. That’s interesting because when I think values you mentioned before like trust or I love vigilance , that’s funny. So open to interpretation, but I don’t think of the word reachable as a value. So that’s really interesting to me. Maybe unpack a little bit for me and our listeners, what is Reachability and why is that the first level of value in this framework?
Jonathan Crossland 00:15:44 Okay, so the maturity index is what you alluded to. So AMMERSE has the seven values in the mnemonic, and then it has the maturity index where it has these levels, where it groups the values together to show you how mature you are, right? In terms of process or in terms of business model and so on. So the reason why reachability is a value is because it easily encompasses being reachable, reaching a goal in budget, reaching a goal in time, reaching a goal in skill. So if you value somebody, somebody’s talent or somebody’s hard work ethic and they are reachable to you, and you combine to reach for a goal, there is a value there. So two people combine motivated to reach something. So reachability is a value category that encompasses all those sorts of values that would make you collaborate with someone that will make you be open to reach a goal that will make you rely on a budget or understand what a budget is.
Jonathan Crossland 00:16:51 So it’s all the things related to reaching for the goal and solvable, which is also level one in the maturity index. I usually say it as reaching to solve. And the reason why it’s level one is because we as a business or as human beings, we enjoy solving problems. But you can’t solve a problem with unlimited amount of time. There has to be some timeframe you reach to solve, and your reaching is what? Well, to maybe an academic, in an institution it might be two years, to NASA maybe 20 years, to a small startup, maybe six months. How you reach and what you’re reaching for. So the value category encompasses, just keep in mind, it always encompasses a whole set of values that people who are reachable and approachable in that way would encompass. And so I do have a list of these values, which I haven’t published yet, but I’m, it’s in a matter of like process elimination and research really. I intend to deliver surveys and see and sort of plot more values into these categories. I have a fair idea what should be there, but over time I’d like to establish them scientifically and see that they fall into these categories.
Jeff Doolittle 00:18:09 So why reachability first? Maybe it’s obvious but explore a little bit more and in your thought process on how you arrived at that. And I appreciate the clarification that reachability is a category of multiple values, so it’s an interesting way of looking at it. So that’s a helpful clarification there. But why reachability first? Why is that the first step in this process of organizational maturity?
Jonathan Crossland 00:18:35 So if you, if you start a business, you will first start with what is it that you want to provide? Is it a service as a product? Did you stumble on a solution and now you need to reach people and give it to them? The reason why reach is first is because there’s not always a solution. And then we try and reach, sometimes you’re going to start a business and you’re going to reach, and you need to discover who you’re going to reach and what budget you have to reach those people or that market and so on. So reachable on a small level or a large level, it has to be something that makes sense, whether it’s an ad hoc coder or a small startup or a corporate. So the reason why reachable is first is because it’s not always the solution that comes first. You are reaching to solve, or you are reaching somebody to give them a solution, but that’s never clear.
Jonathan Crossland 00:19:29 So I chose reachable and solvable to be level one. So really, they jointly level one and all the values are interdependent, right? They have these relationships together, although reachability is first, it’s first with solvable and I think it’s very, very coupled, but it is separate enough for us to know and understand, am I solving a solution right now or am I reaching to solve a solution? And I think there’s a difference in how we approach that. Somebody might be reaching continuously to get nuclear sorted out for energy or make it more efficient or do something like that. It could be a long-term goal. You’re just reaching for something, you’re not sure of what the solutions are. You’re not sure of all the problems, but you’re going to reach.
Jeff Doolittle 00:20:15 And you hope it’s solvable. That’s the idea. Or you wouldn’t be reaching,
Jonathan Crossland 00:20:18 You hope it’s solvable.
Jeff Doolittle 00:20:18 But we’re not sure yet exactly, or we’re not sure how it will be solvable yet.
Jonathan Crossland 00:20:22 Correct. So if you have a solution first, fair enough, you have a solution, but is it a valid solution for a valid problem? And will it fit in an environment? So there’s a lot of other values that will now come into play. And so I chose reachable because I thought that is the first thing, whether you’ve got a solution or not, you’re reaching.
Jeff Doolittle 00:20:42 Okay, so level one to sum up is we’re reaching for a solution. We may have one, and we’re figuring out how to get it out in the market, make people aware we’re reaching out into the market or we’re reaching for a solution and trying to discover perhaps a solution. And then it sounds too, you mentioned that these are organizational values, but there’s a personal aspect of this as well. So am I reachable as a person? It sounds like that’s another way of looking at this. So how would an organization, how would I, as a business owner use this to help reach this first level to, sorry, to overload the term, to achieve this first level. Like what does it look like when I’ve achieved this first level of maturity with reachability and solvability, right?
Jonathan Crossland 00:21:31 Yeah, just to knock a point home before I answer that. And that is, AMMERSE is a language where you have the benefit of using all the same terminologies across any department, right? Any person. And so there is an ambiguity there sometimes, or you may feel that there is because, am I talking of this now in a personal capacity or so on. But the categories that I’ve come up with here with these values, I’ve really thought hard about whether the personal in the organization would align. So reachable is really, whether it’s what you feel is a personal value, it still aligns very much for the organizational equivalent. So reachable, what it looks like is that if you are looking at code, you could see this if you’re a coder, you could see this, I hope the analogy would help. It is software engineering, of course.
Jonathan Crossland 00:22:26 So I expect it to hit home. But if you take a code base where somebody has tried to solve a problem, it kind of has a different feel, a look about it then to somebody who’s already established how to solve the problem and has thought about it and elegantly executed. You know that code that you’ve got that’s commented out and you weren’t sure, and you, I’ll leave it there for the moment and you’ve refactored and you’ve changed things and you’ve tried again, and you’ve ran it and you’ve debugged it. And that’s what an organization looks like. It feels that way. It is that way because all they’ve worried about, all they’ve been concerned of is reaching the goal. And in that you’ve got no time to faff around with anything else. Is there a meta problem? Don’t worry about it now
Jonathan Crossland 00:23:12 Can we do this? Well, I’m not sure, forget about it, we’re trying to solve this problem. Remember this is the problem. And so an organization, just like our code, will mirror and reflect those two values because those two values are what we’ve been aiming for. And so in an organizational field, you might find processes that are ad hoc, lack of process, maturity, nothing embedded. People are just doing all sorts of things to accomplish things. There’s nothing set in stone. You may find that there are one or two solutions that are not compatible with each other. They sort of cross purpose. Maybe the solution is not all encompassing. Perhaps the solution doesn’t cover all the bases. And so maybe you are late with deadlines, possibly the budget is too small. And then you have to reiterate and do a next iteration. You will see characteristics of just reaching and solving. You will see it a mile away.
Jonathan Crossland 00:24:14 And we can call that a prototype. It’ll feel like a prototype. It will be a prototype. If I’m inventing something, it will have cardboard and sticky tape and everything else holding it together, and it won’t be a product. So I think ritual and solvable, if you think of it from that point of view, you can see it. Now, obviously that’s subjective. I’m giving you examples of this. And in every context it’s a bit different. And the first level of AMMERSE is really to understand for yourself what these values mean in your context. And it may be slightly different. That’s the whole point, right? Of values. And we’ll get into weights, I’m sure, but reachable, I could reach for something but only be 50% a part of that, that reachability, it’s only 50% of my efforts are going into that. It’s not 100% solvable for example. So it doesn’t have to be a binary thing.
Jeff Doolittle 00:25:09 Right? So I’m going to briefly jump to the end, but I don’t want to get too deep into it now because I want to work through these a bit more linearly. But maybe talk a little bit about what happens if, say you’re in a context where the goal of the business is to reach a solution. So we’re aiming for level one, but we have people on our team who are really, really excited about values that are further down, say, agility, or extensibility, which again, we’ll dig into more in a minute, but speak to that a little bit now. We’re going to get to those and we’ll dive into them a little bit more later. But I want to highlight that now so listeners see where we’re going as well. And here’s specifically why. I think what you just described is what a lot of people think agility means. And yet in the AMMERSE framework, agility comes much later down in the maturity model. So speak to that a little bit for now. We’ll dig into it a little bit more as we go through the levels. But what happens and then how do we deal with it? Maybe if we’re in a situation where there are conflicting values and maybe from this framework, values that require more maturity are attempt, there’s an attempt to apply them when maybe that’s not really what we’re aiming for yet as an organization.
Jonathan Crossland 00:26:25 Right so I think the reason why agility is not part of reaching and solvable and why the agile movement may regard reachable and solvable as part of agility or so almost entirely, is that when you’re reaching to solve, you’re going to communicate a lot. You’re going to get short feedback and you’re going to build that prototype. Now, in some organizations that may be enough, and it’s all about context. That may be enough. You reaching towards a solution every day you’re having your meeting, you’re discussing a problem, you work at it, you solve it, you deploy it, and off you go. Reaching and solving. That doesn’t inherently mean that you’re paying attention to any of the other values that come about. Such as, am I, is this fit for purpose? Am I building something skew, right? Am I going off on a tangent. Am I over-engineering? I’m engineering.
Jonathan Crossland 00:27:21 There’s so many other things to worry about that reaching and solving, if that’s all you feel that agility is, I think agility is more, but if that’s all you feel that it is, then you’re very much mistaken. And also, if agility is implemented within reachable insolvable. So in other words, now I’m also trying to adapt to agility. What of all the other things like just neatness, tidy, maintainability of my code base. Can I roll out my code to another region? Well, it can’t even deal with this new date format, right? But here I am expressing an entirely new process that the team is going to go through. We’re going to do CICD, but the code base is not even ready. So I think the reason why mine is agility, we’ll talk later about it, but agility to me is something else. It’s an add-on to reachable and solvable.
Jeff Doolittle 00:28:21 So we’ve covered level one with reachable and solvable, and then we start moving into level two. So describe for our listeners, what are we after with level two? Like what’s the goal? And then in this case, there are three categories of values that we can kind of walk through in level two of this maturity model.
Jonathan Crossland 00:28:41 Sure. So, there are many competing methodologies on how we accomplish something, whether that’s in software or anything else. If you reach to solve and you reach to solve and you’re building what I am imagining to be valuable, but quick in one organization, it may not be adequate. You need checklists, you need some level of quality and so on. If you’re going to add that to level one in terms of the process with the mindset of reaching unsolvable, you may not be looking at these other values that I’ve got in level three. So that’s why they’re now level three to get your attention and say, right, level three is important, you’ve been reaching and solving, but what do you now need to do? The three values there are minimal, environmental and maintainable. And so it’s obvious, if you think of a bit of code, you’ve written some code, you think it’s the solution, now you understand the problem.
Jonathan Crossland 00:29:45 Now it’s time to make that a bit more minimal. Now it’s time to think about maintainability. How am I going to maintain this later? Now’s the time to think about the environmental consequence such as, oh that’s Java, it’s not JavaScript, right? Okay. Oh, hang on, I’m going to have to migrate this now because it’s actually in the web context. I’ve been sitting in the wrong environment, so whatever it may be you’ve got to look at those three values and add it to the reachable and solvable because what you’re trying to do is make something long lasting. You’re trying to make something that not only solves the problem that you set out to solve, but solves it fit for purpose, solves it elegantly, solves it in a way that can be maintained so that next year it’s still solving the same problem or perhaps environmentally when you release it, it solves the problem for that environment or another environment and so on.
Jonathan Crossland 00:30:40 So the contexts are important, and that reminds me of, it works on my machine, right? So you’ve built something, reachable and solvable. It works on my machine, right? You commit it, everyone has a hernia because it’s not neat, is not maintainable. You have put no thought into this. So what’s going to happen is it’s going to be rejected and you’re going to have to spend some time making it more maintainable, a little bit more fit for purpose. You’re going to have to think it through, make it solve meta problems as well. Because you’ve just introduced a whole batch of those. Think about the environment, you weren’t using the same code, language, whatever, right? So, you have to think about those three things and that gives you that maturity. If you take a solution that you’ve got and it’s a bunch of sticks sewn together and there it is, that’s one level of solution. And the next level is improving that and making sure that it’s fit for purpose now, fit for the environment.
Jeff Doolittle 00:31:30 So is there a risk in waiting to think about maintainability until level two, for example? Of course. Oh, okay. Well yeah, of course. Talk a little bit more about that.
Jonathan Crossland 00:31:40 Yeah, well it may or may not be depending on the context and that’s why AMMERSE makes no judgment call and it’s not a framework for saying to you, you must follow these levels, right? It’s a level of maturity where the usefulness is to inspect what you have and say, what do I have here? What values have I been implementing or adding to the system? And it’s a mirror, it’s a reflection and then you can see the maturity. But if you have a good team and everyone’s pretty good at their jobs and you’ve got good budgets, you’re well established, good client, customer base, you might say, we aim for level two immediately with absolutely everything we do. And I’ll give you a little analogy. If you take test driven development, it’s reachable insolvable. What they do is they reach, they write a test and then they solve that, and then they iterate and they reach and they solve and they reach and they solve. And then they need to refactor. And refactor is considered a positive term in this regard that you’re now positively refactoring and therefore you iteratively improving the test and the code. And so therefore, what are you doing? You’re adding minimal, maintainability and environmental factors to that test and to that code base iteratively making it better. So TDD in essence is reachable, solvable first as a process, and secondly adding level two. So I just brought that analogy in because it’s a coding podcast after all.
Jeff Doolittle 00:33:15 Absolutely. And I think that’s a helpful clarification there. And also, you definitely helped refine the word refactor, which usually just means rework. But in this case you’re saying, let’s take something that works, let’s improve it by making it maintainable, making it minimal, and considering these environmental factors. So, and as you said, there are risks to just being reachable, solvable. And, if you’re just reachable, solvable, that analogy seems to imply, maybe it solves the problem, but it’s a mess. Nobody can understand it. My favorite example there is you get blame later and you discover that it was you that wrote that horrible awful code. So maybe you should make it maintainable to help you. Something else I appreciate that you clarified is one way to sum this up is it sounds like you’re saying that this framework is more descriptive in some ways than prescriptive. You can use it to help come up with prescriptions, but it’s more helping you describe how are we operating and then possibly use it to consider how could we operate? Is that a fair assessment?
Jonathan Crossland 00:34:15 Correct. So the AMMERSE is a value system and in that sense of the word, as in complex system or systems thinking. And the idea is that we’re not in a linear anything, right? We don’t have a roadmap, which is not a map or a road, which road are we on now, which team is on which road going in which direction? Values are more helpful because we can look at a system and say, what is the current state of the system? We can ask good questions, we can use AMMERSE to come up with a set of questions relating to that category and ask it of the system, are we reachable? Do we have enough budget? Is there enough time? Are we placing efforts into minimal? Are we placing efforts in maintainability? Where is our agility? Right? Is it everywhere? Is it, do we need to apply agility in every area?
Jonathan Crossland 00:35:15 Is it a mindset that the whole company must do or is it just a part of the code base that needs to be agile, right? because we’re going to different territories. Is it aligned with the fact that our business is going into different territories? So the code base needs to be a mirror on that strategy, right? So if we are reachable, our code needs to be reachable. If we’re agile, our code needs to be agile. And so yes, it’s very much a reflection, a mirror to check the current state. And then in AMMERSE, I’ve got the good old gap analysis, right? So where do we want to go, right? Is this ideal? Like where is our ideal? And it’s not about saying, well, there’s an objective, we’re marching on a road to get there. It’s more of a what do we tweak? What value do we tweak in our system that will align us or move us in that direction?
Jeff Doolittle 00:36:07 So level one, we are reaching for a solution, and level two, we’re tidying it up, we’re fit and finish, right? We’re making it, as you said, maintainable, environmental and minimal. And we’ll get to level three in just a moment. But explain a little bit more about, you mentioned before these are value categories, they’re groupings of values. So what are some of the values that you would say fit within each of these three categories? So for example, what does it mean in your mind to be maintainable specifically?
Jonathan Crossland 00:36:41 So maintainable is something where you can go to something and improve it or ensure that it remains in its same state, right? So naturally entropy and all sorts of things kick in. And maintainability is maintaining the standard or maintaining the level in which you set. And that could be at any level that you set. It’s just that your mindset is, am I thinking about maintainability, right? So the values oriented around that would be diligence, discipline, right? Wax on, wax off, right? So it’s that kind of idea. And if you place somebody with those kind of values, somebody who you’ve learned that their hobby is let’s say old cars, antique vehicles, and every weekend they’re out there buffing and cleaning and they’re meticulous. Well, they’re probably a candidate because their values align with maintaining historical value and keeping it up to date. And you can see that personal value reflecting in what people do.
Jonathan Crossland 00:37:50 And therefore you can say, well, you’re the perfect guy to manage the maintainability of this code base, make it shine, right? And you’re probably giving it to the right person, . Exactly. Yeah. Minimal is each of these categories is also, an entry point, a doorway to a process or a framework. So imagine the reachable framework, which is all about reaching. That’s all it’s about. And you can, you can orient your entire business around that and has processes and it has things that you’ve built on being reachable or level three, which is agile. You’ll start in a minute. You can build an agile methodology all around being agile. And so each of these value systems lends itself into that whole world. So you asked a question, which made me say that now, and I can’t remember what you said, but I think each value, it’s very important to understand that it’s how you prescribe what you want to do with those values, right? So if you’re agile focused, then you can use an agile methodology.
Jeff Doolittle 00:39:02 So you’ve explored a little bit about maintainability. Let’s talk a little bit more about minimal and environmental and what are the values that you would see there? And maybe as you said, you could have a methodology for each of these particular, I should correct myself, value categories. So what does environmental specifically mean in this level two of maturity?
Jonathan Crossland 00:39:24 So environmental is something where you’re going to say, well, we care about things aligning in the world. We care about sustainability. In terms of a software design pattern, you would care about the adapter pattern because everyone can adapt to the same thing. You care about polymorphism, you care about things that align with that concept. You care about neatness of code, conventions because you’re environmentally friendly. You don’t want some, you don’t want to design something and have someone break the design, throw it out the water, right, not implement the right interface, throw it in the wrong place, then they’re not adhering to the environment. Somebody who’s environmentally focused will really, really take care of the ecosystem that’s already there and will expand on that ecosystem in very good ways. They will be sensitive to those kind of values that you have. And yes, they’re personal values and you can think about that, just sustainability. Somebody who’s diligent about recycling is probably somebody who cares about the environment, which is probably somebody who cares about coding conventions. Look, it’s a leap, right? But that’s the sort of idea, the thread that you can follow.
Jeff Doolittle 00:40:49 Maybe another example for environmental might be creating dev containers so that everybody has a consistent development environment, correct?
Jonathan Crossland 00:40:58 Absolutely. And if I was to build a methodology around minimal, I would probably create lean, right? Because that’s what it’s about. Minimal. It’s about reducing waste. It’s about making something just right fit for purpose, getting rid of all the fluff, getting rid of all the things that don’t matter, building it to its core. And that’s something that, that the lean has. So I think each one of these, and remember it’s weights, right? We can, it’s not that we have to fall in one camp. And I think if there’s any motivation behind AMMERSE, it is to explain to people that you and I value different things and we can still work together and we don’t have to be dogmatic.
Jeff Doolittle 00:41:41 It occurs to me as well that we could apply this not just to coding and not just to our business, but it appears that we could apply this to how we do software architecture. Thoughts on that?
Jonathan Crossland 00:41:54 Well, on the website I’ve got a software architecture post which talks about how we can use that. And so there are many sort of problems that we have in software architecture, right? Trade-offs. We must understand which solution is going to work out the best in this scenario and it’s temporal. So over time, our best solution today is not the best solution then. And we’ve got to play that game. We’ve got to understand what is the tradeoff we’re making now and is it going to have an impact if force A and force B come into light next year? Should we build scalability now? And so we still kind of want to do the AMMERSE maturity with architecture. What we’d like to do is we’d like to say, what is the problem we’re trying to solve here and how are we going to reach it? We’ve got to look at our developers and say, are they good at that?
Jonathan Crossland 00:42:48 Can they do this? Have we done microservices before? Do we have a department that does deployments? What is it that we’ve got here? How much agility do we want to build into the system? Is an extensible, we’ll get to level 3.1. Is it extensibility that we’re after? Is it an ecosystem? And so our software architecture is tailored towards the weights that we would apply to these values. And getting it right is, is difficult. Like it always is. But I feel that AMMERSE, and by the way, AMMERSE one of the first, the early incarnations of it was I had the problem solution statement. It’s very much like the architectural design records that they have now. The problem was you write it down, this is the problem that we’re trying to solve the solution, this is the solution. And then you’ve put your weights down for your solution.
Jonathan Crossland 00:43:38 So your weights for each value where we’re just trying to reach and solve these zeros for all the rest. Like that was the thing. And when you look at it a year later and you look at it, you can tell straight away they weren’t simple, they weren’t implementing agility or extensibility here. It just needed to be done. They had to do that. And it was a nice reminder or at least a love letter from the architect to your future developer or self as to why you did something and why it was chosen. Often that’s completely gone, right? You don’t understand. I’ve seen many things I’ve done. I’m going, why did I do that? There must have been a reason. It’s so stupid, right? Why did I do that?
Jeff Doolittle 00:44:20 Whack, whack hack and then describe .
Jonathan Crossland 00:44:21 Youíre quite right. Yeah. So I used to use AMMERSE in that respect to kind of give myself a hint as to what the values were, what were the things that I would, was most concerned about at that moment.
Jeff Doolittle 00:44:33 Interesting. And then you could come back later as you mature and decide that we’ve built this, this solution that is becoming unmaintainable and it is not as minimal as possible and it is not considering some of these environmental factors of ease of understanding, ease of portability or whatever these things might be. And you can start to move in the direction that you want to go. So that’s levels one and two. So we’ve got, we’re aiming to reach a solution, we’re now tidying it up and now we get to level three. And this is where you recommend that we begin, I donít know if you recommend, this is where the framework says that we’ve reached a level of maturity where agility is now something to consider. Which again, I think might be a question listeners might have, is we should be agile from the start. So talk a little bit about what it means that in your mind, and again, you didn’t say you have to do these one at a time, it’s a way of looking at what you are doing and comparing it with where you want to be. But clarify a little bit why in your mind agility is a level three of maturity and not a level one or a level two.
Jonathan Crossland 00:45:46 Okay, so the traditional agile, I can say traditional agile, it’s 20 odd years, right? I mean Ö
Jeff Doolittle 00:45:52 Yeah, it’s been around for a while.
Jonathan Crossland 00:45:53 , It’s been around. So what you need to do here is you need to iterate and you need to have constant feedback. And what you find in the field is that customers don’t know what they want. That’s a common thing. Customers want something and then want something else. Projects are being outsourced and the customer or the stakeholder wants a fixed something. They’re not happy to just let it run on and on and on three weeks, five weeks, when are we finishing? Is there a deadline? Well, I can give you, I can install now it doesn’t have the PDFI wanted, right? That’s the conversations that you have. People want fixed costs or at least they want to understand the ballpark. So you’ve got that kind of scenario in the real world and you’ve got this kind of method saying, well, it’s okay, let’s just communicate together a lot more.
Jonathan Crossland 00:46:45 And you can get somebody, this perhaps is more XP than it is agile, although lines are blurred. Bring your customer and let them sit in our team, let them see what we’re doing and participate. Let’s give daily releases. So you can see. In 20 odd years of doing this sort of thing, it’s happened maybe twice that a customer looks at that release and gives feedback. They’re not around when you want them to be. They say something in a meeting and you say, well, why didn’t you bring that up three months ago? There’s so much of that going on. What do we do? Do we educate our customers to be agile? Our technologies to be agile, our people, our mindsets, our everything. So the only reason why agile will succeed 100 is if everyone is agile. Everyone. Well that’s, it’s the real world is that people are going to be something upfront, something this, something that they’ll have an expectation, they’ll demand something. Stakeholder will demand, he might be old fashioned. This is the real world. We’ve got people with different understandings and different values. So in a setting where every single person is behaving according to the agile short iterations helping you short feedback, everything’s swimming. Sure, great, but does everyone have that environment? And is it good for everyone to adopt that? I donít know.
Jeff Doolittle 00:48:16 Well let’s talk about that a little bit because we see across the industry, you mentioned before virtue signaling. And it seems in my experience, you tell me if yours is similar, that a lot of times the word agile is virtue signaling. It’s we’re doing the ceremonies, we’re doing these things, we’re following these. And to your point, maybe it’s not really working for you. And that’s one of the things that intrigues me about this AMMERSE framework is it can perhaps, you even mentioned earlier when you first read the manifesto, what you did is you deconstructed and you thought about it. You didn’t just say, well let’s go with this. This sounds good. So, speak because I’m sure to some of our listeners might feel this is controversial. Theyíre thinking well, we’re doing agile and it’s working great and whatever it is, how do you evaluate that? How do you determine whether or not you actually have agility as opposed to practicing ceremonies that have the word agile sort of bolted onto them?
Jonathan Crossland 00:49:14 So we like adding a positive or a negative to something and we’re biased. We will add a positive if we think it’s good and we enjoy it. Take refactoring. Refactoring is neutral. Refactoring is re-factoring. I previously factored, now I’m going to refactor. What is inherent in the word refactor is only one thing, that’s changed. If I’m refactoring I’m changing. That is it. That is inherent. I’m changing for the good or the bad, who knows, right? If a whole team of people say, you don’t tell me to refactor, I’m a professional, I’ll refactor, right? I’ll refactor it. Nobody can stop me from refactoring. It’s part of my job. You’ve probably heard that sort of thing going around, right? It’s a very arrogant view. What they’re effectively saying is, I will make a subjective call as to whether that code is correct or not and modify it subjectively inducing change into the system.
Jonathan Crossland 00:50:16 And I’ll do it if I want to. That’s a very bad bias. Refactoring is neutral, but people, if you ask out there, they’ll instinctively think and attributed to a positive action. Refactoring is positive. Controversially, I think refactoring is a code smell because I think whenever I see refactoring going on, the questions, the alarm bells that go off, the smells that I get is, why did we not finish that? Is that not done? I thought it was done. Are you changing the tests as well? Are you doing this? Do we have to get our customers to approve it again? What’s going on here? So I don’t see it automatically as a positive. I see it as an action of change. And then I’m thinking, well, do we have processes involved to deal with that change? Now, really it’s changed. Refactoring is change inherently. Do we have change management in place?
Jonathan Crossland 00:51:09 So we are really talking about here, the question is, is it the right time for agile? Well, if I don’t have change management, but I’ve got the philosophy of refactoring at will, then is that the right time? So change management goes together with TDD, we might say, well we test and now that helps us minimize change. But does it, does it minimize all change? It’s not all change. What about documentation change? What about getting the user to understand the change? There are many, many things that would change. So I don’t feel like people are looking at things from a value system and saying, I value refactoring. It’s positive to me, it’s my value. Okay, is it a value of the system? Does the system require tons of change and agile, all the processes are to embrace change and deal with change, but all the practices make change.
Jonathan Crossland 00:52:13 So let’s think about that. It’s a self fulfilling prophecy. I will refactor in. I want induce change, but I need change management. I’ll do TBD to handle that. We’ll do CICD, I’ll give change to my customers immediately via a pipeline. Change, change, change, right? When is that going to end? Is there a cliff? Is it get, does it get faster and faster? Okay. So I feel that agility is part of our answer. We need to get feedback, we need to talk to customers. We need to do things in smaller bite chunks and not bite off too much. We need to do things like that. We need immediate feedback, but we also need long term feedback signals, right? We also need stability. We also need to understand when change is good and when it’s not good. And so I’ve put agile level three because I feel it’s the best time value wise and it’s no judgment, just the value wise.
Jonathan Crossland 00:53:15 Now that I’ve reached and sold something and I’ve reached it and all’s good and I’ve made it a bit more minimal and made a bit more elegant. And I’ve looked at maintainability and it’s a bit stable now. It runs in different environments, in the environments at least that I wanted to run in. And when a new developer comes, he picks up on it with the coding guidelines. He understands it. It’s got right amount of documentation. Okay guys, we’re ready to go into the next territory. How can we make this code base more agile now, right? It’s probably the best time. Tidying what you’ve done is an important concept. So if youíre a garden, you’ve had a nice party, the garden is spewed with all sorts of things, beer, cans, everything, lying in the garden. If you’re that way inclined, right?
Jonathan Crossland 00:54:00 There it is. You say, right, today is the day that I clean the hedges, mow the grass and do everything. It’s probably time to clean first, right? Probably have to tidy up everything. And then if it’s too late and the sun’s gone down, schedule another day to do the mowing. You can’t do everything at once. And you have to pick the right moments. So to me, level three, the reason why you may have more success with agility and with being agile and having pipelines and doing test driven and all those sort of things is perhaps the code base is mature, it’s neat and so on. Or perhaps it’s fresh, it’s Greenfield and you can start it all and you’ve got the budget and people have given you plenty of time to reach that. But that’s not indicative of all contexts. So therefore it can’t be the answer for all contexts.
Jonathan Crossland 00:54:56 And if I start to draw a line and put on the one end ad hoc coder working from home office by himself for one customer and all on the other side, software engineering, checklists, regulations, the best practices we can adopt, constantly improving. If I take refactoring or TDD or anything, where am I going to put it on the line is going to be where the most positive, the most negative is. And as I shifted around, the positives and negatives are going to change if I’ve got three people, 10 people, if I’m in this environment or that environment. And I think the bias is really thinking that there is one fits all. That that practice fits all, that methodology fits all. And I think it’s an evolutionary thing. Another reason why AMMMERSE is around, in my opinion, why I think it’s heartfeltly, right? Why I think people should look at it and think about it more is to think about where their solution fits. Is it this, is it that value, is it more of this value? And then look at their context and adjudicate where it is, and which methodology would align. We can’t all go to AWS, there’s got to be other hosting platforms doing other things, right? We’re not all going to live in one place.
Jeff Doolittle 00:56:09 And sometimes an on-premise solution is still the right solution versus a distributed cloud solution.
Jonathan Crossland 00:56:14 Correct. But look at us. We dived right in, right? We dived right in and we tend to do that.
Jeff Doolittle 00:56:21 Yeah, I think it’s interesting too when we talk about maturity as we consider agility and the Agile Manifesto, it was created by a group of individuals who each had, I believe at least 20 years of experience in the industry at the time. Now they all have over 40 years of experience each in the industry. And they were talking about how they work together. So talk about maturity. You’ve been in the industry for 20 years and if you’ve been in the industry for 20 years, especially the people that we’re talking about here, that weíre a part of that group, they were talking about how they work and if we apply that to a brand-new team, what’s been your experience with that kind of approach? Perhaps trying to apply principles that were created by individuals with a lot of experience now being brought to bear on a, say brand new development team?
Jonathan Crossland 00:57:10 For sure. My eyes weren’t always open in this regard. I’ve started a project five devs on my team. I had a software house. I’ve got people, we’re going to build this. This is what I’d like to build. Go and contact these customers, see if they want to buy into this. No, we don’t have anything yet. It doesn’t matter. Go and talk to them. Go and see what they want. You start on a template, get it going right. Just start something. We’re going to just iterate and just get something going. Three weeks from now, I’m going to set up a meeting, little mini conference. We’ll invite some people in that industry to see if they want to join forces. It doesn’t work. Well, at least it didn’t for me. Maybe it works for somebody else. The reason why it didn’t work for me is, customers came with, well, what have you got to show me?
Jonathan Crossland 00:57:55 Oh, I’ve already got this and this. Does yours do those things? Oh, great, I can write that down, but I’m eight months away from implementing that because I don’t have these other things. So it’s useful. It’s useful, it’s good, but it doesn’t always work. The conditions have to be right. And so I think whether it’s Greenfield or not, I think a lot of people get caught up as, as you said, the AM authors are in an environment people who have written books, well-established, worked at all sorts of large companies. Being asked questions, important questions. How do we roll this out to a customer? Well, how many users you have? A hundred thousand. Okay, well is that the same answer to, if you’ve got five partners and there’s only 25 users across those five partners and you’re very established, but it’s not a big deal, it’s not a big scalable system.
Jonathan Crossland 00:58:50 It’s a monolith. It works. Are you going to think in the same way? And, and the unfortunate thing is that there are probably a hundred thousand development teams like that that go, oh, microservices and off they win, modifying their code, moving it, changing it, getting it to something else. And it’s just another incarnation of the same thing. A trade off, new problems instead of the old problems. And I’ve been in this game long enough and I’m sure you have as well yet another class named user, yet another class named whatever. You see it again and again. And you may get a new framework that you install and it’s a different set of problems. And people are hopping from one framework to another, just inheriting different problems.
Jeff Doolittle 00:59:40 And now we reach level 3.1, which is extensibility.
Jonathan Crossland 00:59:45 Another controversial one, I think.
Jeff Doolittle 00:59:47 Yes. So, again I can imagine someone saying, well, we want extensibility from the start. Why would you put that so far down in the levels of maturity? But what happens when, again, people try to jump straight to this and maybe ignore the previous sets of values? And what does it mean in your mind to be extensible and how do, how do teams achieve it and how does AMMERSE help them achieve it?
Jonathan Crossland 01:00:10 So I think if you, if we first take a business analogy and we say, right, we have a business model and we’re starting out small, we’re going to solve that problem. We’ve got a small customer base and we try and improve it for them. And then we become agile and we want to modify some things and satisfy them in short spurts, get something they’ve requested, make them happy, right off they go. Extensibility is, is basically agility. Level three is agile. Level 3.1 is extensibility. So it’s only a 0.1 change. And it’s an important one. What you’re doing now is you’re codifying, whether that’s in process, mindset, values or code, you’re codifying what it means. That agility, what it means that agility in terms of plugin ability. So it’s no more just about being adaptive. We now understand how to be adaptive in this area.
Jonathan Crossland 01:01:09 And this area of being adaptive requires these sorts of interfaces and plugins. And we will create those plugins. We now know we need to integrate with that API or those things, we can build them. And so it’s not just good enough. And I think this is where agility and the controversial bit is. I think the agile movement has one more step to go that’s turning themselves into extensibility. And that’s when we come of age, when we understand the difference between design time agility and runtime agility in that sense, where we’re actually building and planning ahead to build an ecosystem that parts are modular, that pieces get plugged in and they just work. You don’t have to recompile the beast, right? So I think it’s a minor step up, but I think extensibility is the maturity that you now get from understanding the previous levels.
Jonathan Crossland 01:02:04 And to answer your question, no, I don’t prescribe that you don’t have to start at extensibility. You can if you’ve got backing from a venture capital firm and you’re going to take on Google Docs, and Google Docs or any other platform has an ecosystem, the ecosystem, the plugins and so on, they’ve got a very, very big developer community. Straight away that has to be your part of your strategy. Are you going to emergently design a plugin system? Probably not. Are you going to eventually get to a plugin system? Probably not. But extensibility is a much higher level of complexity. It requires more effort. It’s in, on the one hand, over-engineering, if you don’t need an ecosystem. So that’s why it’s right at the end, 3.1, you have to be agile in what you do in order to be extensible. If you’re not, there’s a miscommunication or a misalignment of values.
Jonathan Crossland 01:03:03 Imagine you’ve got an ecosystem with plugins and somebody contacts you and says, I really need a plugin to do X. And you can, your answer is, well I can’t do that. Why would you say you can’t do that? Surely your agility is at the right level for you. Extensibility, it goes hand in hand. Surely by doing plugins, you have a minimal and maintainable system that you can support the plugins. Because if you’re not ready with all of that and you just build an extensibility, what you’re going to do and what’s going to happen is, and you’ll see it translate in teams, our API has changed. Oh, everything’s broken, right? This happens again and again and again. When you’re not ready, you don’t have change management in place, you don’t have versioning of your APIs in place. You don’t have different customers on different versions of the API, some proprietary. You can’t do that. You can’t fit it in, you can’t build for it, you can’t scale with it. And so you’re not ready for extensibility. So you can introduce it right in the get go, but you’re going to pay that price. Takes a long time to get there. Yeah, correct.
Jeff Doolittle 01:04:10 And in some, it sounds like that’s essentially a lot of what AMMERSE is about is identifying the trade-offs between values that may be competing. And if we, if we value everything at once, we don’t really, it’s like having everything’s the first priority, well then nothing’s the first priority.
Jonathan Crossland 01:04:25 . Correct.
Jeff Doolittle 01:04:27 And so this is giving us a way to think through what our actual priorities currently are, and then perhaps think about if we want them to be different, how can we start to do that gap analysis and move from our current state to where we want to be. And all in the context of, as you mentioned, change management and how we organize to achieve business objectives.
Jonathan Crossland 01:04:50 So I think just sort of to wrap it together, because it seems logical and that is AMMERSE the different layers that you can apply is AMMERSE is itself using itself. So if you want to use AMMERSE at level one, all you need to do is follow the first two principles, reachable and solve. Now how do you reach AMMERSE and solve with AMMERSE? Well, all you really have to do is get to know the values and talk about it. That’s all you have got to do. People inside a team just has to start using the language and getting familiar with saying that’s unreachable. Solving that problem introduces more problems. I cannot handle the additional meta problems right now. We haven’t maintained the last set of features that we’ve built in the last six months. It hasn’t got to a maintainable level yet. So level one really is just understanding and using the language. But if you look on the [email protected], you’ll see that there’s so many layers that you can then add on and use as weights and collaboration systems and, and everything else.
Jeff Doolittle 01:06:03 Well, that’s a great wrap up. So if people want to find out more about what you’re up to, where do you recommend they go?
Jonathan Crossland 01:06:08 So I’m starting a YouTube channel. I’ve got one subscriber and that’s me. And it’s a very dangerous thing to start, right? Because nowadays you have to make a video one per day or more to really get it promoted. But it, that’s not the purpose of it. The purpose is to just convey the ideas of AMMERSE small item by small item. So if people are interested, they can search for AMMERSE, A-M-M-E-R-S-E on YouTube, go to the AMMERSE org website and see the link and then just sort of learn about it. And the nice thing about AMMERSE is that it fits within everything. because it underpins everything. So whether you don’t have to give up anything. You don’t have to reject anything else. You just have to understand why you accept certain things and why you reject other things and understand your values and your team’s values.
Jeff Doolittle 01:07:00 Well, Jonathan, thank you so much for joining me today.
Jonathan Crossland 01:07:03 It’s been an absolute pleasure. Thanks, Jeff.
Jeff Doolittle 01:07:05 This is Jeff Dolittle for Software Engineering Radio. Thanks for listening.
[End of Audio]
