[Are you truly involved in the developer communities you work in and sell to? Are you seeing the value in the events that you are a part of? DevRelate.io can help. Developer and Community Relations as a service. We speak developer. Learn more at DevRelate.io or email us at Info@DevRelate.io.]

JANELLE:  Hi everyone. This is Episode 123 of Greater Than Code And we're going to do something a little bit different today. We're doing a reading group. I have this book on my shelf, 'Zen and the Art of Motorcycle Maintenance' by Robert Pirsig for years and I haven't actually read it until fairly recently. I'm actually kind of glad about that because this book seems more relevant right now really than ever.

Today on the show, what we're going to do is have a group discussion about the insights in this book like if we think about this perspective as a lens, as a system of shapes and use our engineering modeling skills. How can this book help us understand what's going on in the world right now and what we can actually do as individuals, as communities, companies, as an industry of software engineering to build bridges that can help bring humans back together again at all scales, really?

I'm here with Bryan Karlovitz and John Sawers and we're going to have a really fun discussion today about this book. On the back of the book, there's this inscription that says, "The extraordinary story of a man's quest for truth. It will change the way you think and feel about your life." This is one of those books that has definitely affected the way I think about things.

A little background about me and why I wanted to talk about this. I've been researching this data collection techniques for the last decade of measuring the pain and friction and idea flow, as I call it. Imagine this flow of ideas between the developer of the software and the friction that happens along the way, this friction in human communication. Whether I'm trying to explain an idea to a machine or I'm trying to explain an idea to another human, you can imagine there's friction in this communication pattern. At this point, this paradigm of idea flow networks became the way I started to look at everything, so if I think about all the humans out there in the world having these wires between them and sharing these ideas flowing around these wires, culture becomes this emergent property of these ideas flow network systems, so keep that thought in your head for a minute.

Then in these last of couple years, has been this whirlwind of roller coaster and emotional chaos and everything going on in the world kind of affects all of our lives. I know my life has had lots of crazy rollercoaster in it. I'm kind of hitting that -- I turn 40 this year -- like midlife crisis mode too. I'm taking a step back and asking a lot of fundamental, existential, philosophical questions right now like, "Who am I? Why am I here? What's going on with this crazy world right now?" and I look around me and I see this culture war that is polarity and blindness. These two sides that are stuck in the place of self-defensivess, of I am the victim. Because I am the victim, I got to find some other allies that will give me a set of reasons to make sense of my emotions and from studying brains, I kind of learn these three principles around human behavior is emotions come first, then we construct a reality to make sense of our emotions and then, we find allies to validate our realities.

If I think the paradigm of idea flow networks and I think of ideas as flowing around is not only having the shape but also being motivated by our emotions, being motivated by this desire to validate our realities, then you can kind of look at what's going on in the world in this emergent culture, in this emergent tension as a reality construction. We live inside the story that we tell ourselves and then, if I look at the ideas from this book, Zen and the Art of Motorcycle Maintenance and these two polarities, it gives a really good lens for seeing what's going on in the world right now.

Pirsig breaks down these two paradigms, these two ways of seeing that are opposites and I'm going to call these the classical paradigm, which is essentially breaking down the world into boxes and components and models of all the things and using rational decision making around how the world works based on a system of parts and then there's romantic paradigm, which is very gut feel, emotional-oriented, we want to just take this impressionistic feel of things and what matters, what is significant is that emotional impression and that if you decompose the system into its parts this way, it loses its core meaning. These two opposite ways of seeing are blind to one another.

If you look at the world through one of these lenses, the other one doesn't really make sense and one aspect of the story is this journey on motorcycles, the story of motorcycle maintenance. Then the other story, the undercurrent kind of message of this whole thing relates to seeing of the world through this polarity, of these two paradigms and then also, realizing there's a bridge that can be constructed between these two worlds to help us see one another, that there's a possibility for building a bridge that helps us see each other through this blindness.

I start thinking about how can these ideas apply in our relationships at work, in our relationships in our families, how can we build these bridges such that when we dig our heels in, with these opposite ways of seeing that we can find some way to come back together again, to be able to see one another and right now, I think that's probably one of the most important things in the world today -- figuring out how to see one another again.

What I was thinking and where I want to start this is it's really easy to get lost in abstract conversation, so I think a good place to start here is if we dig into these two paradigms, let's just clarify what these lenses and the ways of seeing are, I think it'd be really helpful to look at some examples from the book of how Pirsig explains this.

BRYAN:  The Zen and the Art of Motorcycle Maintenance early on brings up this idea of romantic approach to life versus a classical approach to life and introduces these kind of polar opposite. A classical understanding of the world primarily sees the world as its underlying form. It's the phrase that he uses and the person who thinks from the classical point of view proceeds by reason and laws whereas romantic understanding can't see the world, primarily in terms of I think 'immediate appearance,' so if somebody with a romantic approach to life is thinking primarily from an inspirational or imaginative or creative point of view.

One of the example is showing a mechanical drawing of a motorcycle engine. The person with a romantic point of view doesn't find any appeal in this because what they see is the motorcycle itself, so this drawing is about, "I have the 'dual complex,' list of names, lines and numbers." Whereas a classical person is going to be very interested in this because they're get excited by this rich underlying form of motorcycle.

JOHN:  I think I can add a little bit to there. I felt like one of the things he also talked about was when you ask a person from each of these groups what that means, they'll have radically different answers for you, so the same drawing is, to a classical person, what it means is, "This is how the thing functions and the pistons go in here and the pushrods go here and this is the functionally sub-assembly and the sort of broken down microparts of what the thing is doing," whereas the romantic interpretation is going to be what it means as it means, "I can drive out on the highway and I get the feeling of the wind in my hair and freedom of the road." It's just a completely different answer for the same question.

BRYAN:  And this comes to life in the book with the author versus his friend, John Sutherland who's traveling with him on this motorcycle trip. There's a handful of scenes early on where the author notices some specific issue with its motorcycle and he's thinking about what could be the cause, what exactly does it mean and he's having fun and interested in going into the details of this. John will have maybe the same issue with this motorcycle and it's just an annoyance with him and he wants to pay a mechanic to take care of it. He has no interest in the maintenance or even understanding the reasons for his mechanical issue.

JANELLE:  Do you see the same paradigms and approaches in software like a romantic and classical approach to software development?

BRYAN:  I definitely have that experience, yes. I worked at and that's for my entire career and it's common to have some people on the team who's mindset is just let's get this out the door and working and not really care for the quality or the craftsmanship of the work. We have a side that might have some developers who want to put craftsmanship first and will push a deadline back and back. There needs to be a balance between those two things but engineers on those extremes are definitely something that have experienced in my own teams.

JOHN:  Yeah and I think there’s also a further distinction there from the people who are software equals code, modules, deployments, systems and people who are thinking software is a social construct in a social context, the communication between developers and users and businesses and again, those two things don't really overlap a lot when you're trying to think of what the core issues and the core important priorities are.

JANELLE:  It's interesting to me what I'm hearing here. There's a different from what is beautiful that in some cases is like an internal thing. You might have an engineer excited about what is beautiful from all of these components, the decomposition of the system is beautiful versus an outward appearance of what it looks like on the outside is beautiful and then, I think about like a product person or somebody is thinking about the business and the impact and you can also have these different paradigms and approaches with the different problems. Here I am a product person now and I'm thinking about what is beautiful to me as a product person of like, "I'm able to impact all of these people and having this impressionistic kind of romantic paradigm from a product perspective and I can also have a product perspective and think about the system of parts and the process and stuff of whatever abstractions that they think is beautiful too." You can have a different of shapes you're looking at, a different set of things that you care about and have these opposite paradigms and all of these different contexts.

JOHN:  Yeah. I think it's also interesting much like what you were saying, Bryan earlier that you can't really have a successful organization that involves software without taking both points of view into account because if it's just beautiful to the user right now in this very moment but the software is so terrible that it can't be maintained or deployed reasonably or scale beyond five users, then it's going to fail and if it's super well-designed and abstracted and clean and decomposable but none of the users like it and doesn't solve the problem, it's also a failure and so, you have to balance these two in order to have success.

JANELLE:  I definitely tend toward the romantic side of things. At the same time, there's a romantic aspect to the internal beauty of a system too of like, "Organize it this way and it just looks good. It makes me happy. It's pleasing to the eye. It's beautiful." Even though there is a decomposition of the parts that is elegant, there's an attraction to that initial impression of elegance itself.

I feel like, whether you're talking about internal or external that both internal and external models of the world, you still got these two opposite paradigms in both the internal context and the external context.

BRYAN:  I think maybe the criteria for elegant can also differ depending on what type of a person you are. To stick with the software example, I've work with somebody who thinks their code is elegant if the variables and the functions all have extremely short aims and it can take everything very quickly. But if you try to work on that system, it takes you six months to get used to it and get up to speed but another person might think elegant is, "I've written this in a way so that any team member I work with can understand this very quickly and start being productive."

JANELLE:  Interesting, so it's elegant because it need X and I can type X so quickly. I can make a lot of X's.

BRYAN:  And so, it may be put together in a very clever and an interesting way but it's a whole job in itself to understand the internals and if you're trying to produce software for users, that's in my opinion not very elegant and difficult to work with.

JANELLE:  So clever is a potential attribute that someone might see beauty in, whether or not it has good functional properties for the team. We can go, "That's so clever. It's beautiful --"

BRYAN:  Or very efficient or overly efficient.

JANELLE:  Yeah. This is interesting. I keep going back to the word 'beautiful' because when you're looking at romantic impressions of what better means and what we end up optimizing for, it's ultimately like this emotional experience, this emotional gravity toward what feels like quality.

JOHN:  Yeah. I want to dive into the quality thing a little bit more but before that, that reminds me of a quote, I think it was from Einstein, although it could have been just the internet making that up, that he said that if you're looking at two different equations that solve the same problem, you should always choose the more beautiful of the two because it's more likely to be true or more useful. I thought that was an interesting. You don't hear that language about mathematics very often but I think the idea of quality in most of the book he uses with a capital Q, as a very sort of central concept that he tries to talk about as relating to all of these things and in fact, unifying all of these things, it's still a concept I find myself grappling with. I don't say like, "I think I have my head fully around all the implications of what it means to have this as part of thinking about a system."

But it did remind me as we were just talking about the varying interpretations of what elegant code is. I think people trying to evaluate the quality of code in this abstract sense and they're each thinking of that code as some sort of scale of quality and that you can make things that go higher on that scale but the two... I'm trying to talk about how I'm visualizing this in my head because it's almost like a spatial relationship, where quality is a point in the distance and you have one path going towards that point that as you get closer to it, you have more and more quality and for them, it's readability or ease of understanding or whatever.

Then there's another one where it's like execution speed and so, the higher the execution speed, the higher quality. That's like 30 degrees to the left but still pointing at the same point and each person who evaluates on that scale is thinking that they can get things closer to that ultimate sense of quality by going up that scale. They're all heading to the same point but they're all taking different paths to get there and so, that's where a lot of the disconnect is because people use the one word 'elegance' or 'quality' to describe an attribute or a chunk of code or a system but don't realize that there is these almost opposing systems for defining what that is.

BRYAN:  Or they may disagree with the exact point as to, even if they're using the same measurements. I agree with your sentiment that install grappling and what exactly it means. I think that's one of the big reasons.

JANELLE:  Yeah. It's interesting because I think about this spatially as well but my model in my head is like the reverse of what you just described.

JOHN:  Awesome.

JANELLE:  And then I think of an ideal form as a center of gravity and then if I imagine like a 3D sphere around the center of gravity, that there's a distance metric that as far away from the center and that different people have a different notion in their head of what the center of gravity looks like and feels like and judges the sense of quality based on an almost like Plato's ideal form with a set of deviations around that and they judge a distance relative to an ideal form and yet, each person has their own sort of bounded context of what that means and when they say quality, it's basically like a deviation from that center but everyone has these different centers of gravity about what is better, what is quality and so we say these things, we say maybe these words. In some sense, we have a shared meaning. In some sense, when I say quality, I have this meaning that is relative to an ideal and that concept translates to this notion of quality relative to this ideal. Yet, those specific ideals of what is better, what is quality is like a different gravity and sometimes, those gravities are kind of the same-ish but maybe that's the thing we need to come back and talk about is what are these different centers of gravity. How can we clarify this is my gravity and this is your gravity and where's the differences between our gravity is that we're judging things by and have a discussion about what should our gravity be? What should those qualities be that we actually aim for? Can we come up with a shared definition of better to judge by that gets us on the same side. I think you're right that we take those things for granted that when we say these things, we don't actually mean the same thing.

JOHN:  Yeah. I think that's so common to see, this is good, this is bad code without ever defining the scale upon which that is being measured. Unfortunately, people with more seniority can say those things and then everyone else has to sort of like, "I guess so," because it's so hard to argue about what it is if you just make a flat out pronouncement -- this is a good code, this is not a good code.

BRYAN:  This is reminding me a bit of how the topic was introduced in the book. We have the author and another character in the book is actually the author but as a past self and his past self was an English teacher at a small college. He's started thinking about the question of what is good writing and he would do experiments in his classes where he would show different pieces of writing to all his students and he would have them all vote on which piece was better or which piece have the most quality. This led him to sort of thinking about what does good mean and then this leads into the concept of quality for the rest of the book.

But as I was reading this, I was thinking about if you showed bits of code to lots of developers and have them vote on what's the cleanest bit of code or the most well-written bits of code, what would the result be? Because in the book, with the writing example, the author claimed at least that there was a general consensus of 80% to 90% maybe, of the students are always agreeing on one piece of writing, so would that happen with engineers or even within your own team or engineers who all work in the same language?

JANELLE:  I think we should actually do that experiment in C. I think it'd be really interesting with the results.

JOHN:  Yeah. It makes me wonder if with writing, with rhetoric as he described it in the book, there's pretty much a singular scale of quality. Does it communicate the idea? Does it convinced? Does it persuade? Is it poetically? It seems like those are very closely related and you can say, "Yes or no, up and down on scale," whereas with code, I think because there are these multiple axes is one of the reasons we get so much disagreement and I wonder if there's a way to unify these axes or not and if maybe that's one of the troubles that we're getting into.

BRYAN:  Yeah. I think that brings up a point that there some decisions, like you say with writing words, there's just less directions you can go to judge the quality of something. While we can sit here and think of increasingly complex examples that these has tender actions we can judge, something else might have plenty directions we can change the qualities. There's code but then there's politics and there's what we should do about the United States right now that just get more and more complex.

JANELLE:  Software is kind of interesting because you've got one set of aspects that are 'I need to communicate an idea to a machine.' There's a sense of concreteness to that particular problem that it either communicates the idea to the machine successfully and the code compiles and runs and does what it's intended to do or it does it? Do they got a certain aspect of 'it works or it doesn't' because you're talking to a machine?

There's also this aspect that I think is very similar to writing, where this text that we produce with the variable names and structure and design, any sort of spatial container relationships we create, that's not for the machine. We're communicating and shaping these ideas for each other. It's not fundamentally all that different from writing except it's more structural, so we're like saying, "Here's a container and it's got these thingies in it and it relates to these other things in these different ways and we're modeling space and we're modeling relationships between concepts and using that as a medium for ideas to kind of communicate as a team so that we can work together on translating the set of ideas to something a computer can understand but language itself, the text itself is for humans."

JOHN:  Yeah and I think that might be down to another classic versus romantic split within software. Actually, there's a quote I saved from the book that highlights this difference and I just tagged it because that seemed to apply so well. In describing his friend, John as you mentioned earlier, Bryan, it says, "John looks at a motorcycle and he sees steel and various shapes and has negative feelings about these steel shapes and turns off the whole thing. I look at the shapes of the steel now and I see ideas. He thinks I'm working on parts but I am working on concepts," and I thought that's like you see code and you look at code on one level that it's just sitting there and then there's what does that code mean? What concepts does it relate to? How does it affect the real world? How does it communicate? What it does to other people that are reading it?

BRYAN:  This is an example of the ideal forms. One way to think about coding is you've got certain concepts in the application you're building and they relate in certain ways and you think of that as just these specific ideas in your domain and then we're trying to realize this in a code we're trying to build in a certain way. We're trying to make the code match the domain that we're modeling because it works like modeling.

JANELLE:  Mental model, I think is a good word here.

BRYAN:  Yeah. Making the code match the things. Shared mental model is a very difficult thing to do. I think, the 'share' is the operative word there.

JOHN:  Yeah. Like you're saying Janelle earlier, you can't write a unit test to make sure an idea has been transmitted to another human properly.

JANELLE:  It's interesting though, the things I'm measuring with respect to friction and ideas about three types of things that I measure and one of them is what I call familiarity risk or familiarity friction and essentially, if I think about the software itself as these sculpture of ideas, it's a hodgepodge of things that is sort of constructed by a bunch of different humans and I'm trying to absorb this thing in my brain, I have to read the code, get the ideas in my mind, build a mental model of what's going on and you have to download a certain amount of all this stuff to be able to build that mental model and abstraction in your head, such that you can think about, "I'm going to add a new idea to the system."

There's amount of friction in just that absorption and becoming familiar enough that you get unstuck and so, I measure explicitly how long do we spend staring and looking at stuff before we can make motion, before we can move, before we can start adapting things and how does the area of code that we're looking at, the amount of confusion, the difficulty of absorbing the ideas, maybe the dissonance with the other patterns and stuff, other way in the system, we do all the things one way. Then I come to this other part of the code and all the things are done a different way, I got more friction with trying to get those ideas into my head. It takes me longer to build a mental model that I can work with, right?

Then the other thing I look at is that almost unit testing serve aspect of experimentation characteristics. Another way that I'm trying to understand these things and build this mental model is to prompt things, run experiments and see what happens. One of the fastest ways that you can understand how a system works but you can understand that spatial model of ideas is to execute something and watch what happens and so, then you start looking at these sculpture of ideas as having an interactive surface, if you will where I can poke things, I can manipulate things, I've got various knobs I can turn on the system and I've got mechanisms or I've got windows into the system where I can observe what's going on. I can get output from the system and then I can translate the mix of these inputs and outputs in addition to my reading of the actual code to build the sort of spatial mental model of how the system works, these set of ideas.

What I found as I was doing this, as an explicit definition of better that I started observing these patterns and making the friction and pain visible, that you could start to see across the team how all the differences and paradigms and ideas affected different people. For example, if I'm a human and I think very differently from the rest of the folks on my team, I see these really interesting patterns where one person writes a bunch of code one way and then another person looks at that as like, "This makes no sense," and then he'll rewrite all the code and write it in different way and he see these patterns where people are like rewriting each other's code on a team back and forth in different kinds of ways and it's like, "This is kind of crazy," but at the same time, you've got that dissonance of what beautiful is in these two different paradigms.

As opposed to having a conversation about 'my beautiful looks like this' and 'your beautiful looks like this,' how do we converge on the shared differences of qualities such that we come up with some shared direction we're moving toward, we end up rewriting each other's code. You see this kind of dynamics happen a lot and once you started making these kind of things visible on the team and having discussions about, "Because I think about these things differently," it has these subjective impact on the rest of the team of how much friction it causes in their experience with being able to absorb these ideas and being able to make forward progress on their work. So how does a group of humans can we optimize the idea flow on this network such that we're all pulling the same direction toward more ideas flow across the team that that became a shared definition of quality?

BRYAN:  I think one way to interpret the example you just gave is that, as the team members are talking to each other and seeing each other's code, everybody's idea form is evolving and becoming more similar.

JOHN:  Yeah I've often found that once I understand the scale on which someone else is evaluating code like, "I've just written this code. I think it's really elegant and smooth and I read it and I don't really understand what you're doing here," but then if we can come to that shared understanding, "You've written it in this way because you value these things and that's a good on this scale." Once I understand that scale, as long as I can accept that that scale makes sense to me, then I can incorporate that into my understanding, "This code was not maybe how I would have written it if I just sat down to do it," but it does improve things on its own scale. I can accept that as an improvement without having to be to force the thing into my own paradigm.

I think the more of those that I can collect, the better and I think like Janelle, what you are pointing out is making it more obvious when these sorts of paradigms are conflicting, so that you can make them obvious and discussed and explicit rather than just sort of implicit stylistic choices that I just prefer it this way, which is really hard to argue against and/or integrate.

BRYAN:  Yeah, thinking that in a healthy team, what you usually see is a shared style evolving or a shared code style evolving, a shared approach of all the thing that comes out of hopefully, people with different approaches when each other's approaches and then, kind of finding a middle ground, to use the language of the book.

JANELLE:  And eventually coming up with a shared direction for better, a shared direction for quality through those discussions.



BRYAN:  I think it's also true often that with two approaches, it's hard to argue that one has more quality than the other in most cases. It's just a different way to tackle a problem and where the agreement comes from is with both sides becoming comfortable with the idea that the other side is going for.

JOHN:  Yeah. That's a very good point.

BRYAN:  So what happens is that cognitive dissonance that Janelle mentioned goes away and so then it's not as difficult to start making your code move towards that ideal form.

JANELLE:  I want to kind of throw a wrench into this and I think we can still use software as an example but I want to talk about how emotional motivations come into play in software. The other thing that I see going on is that the software -- our crafts -- become an extension of ourselves and we map a lot of our sense of identity to our code, to our creations that it becomes a reflection of ourselves and all of these things that are difficulty in communication become very emotional.

I'm wondering, as we talked at the beginning about blindness and how kind of our emotions coming into play and create blindness, what are some of the experiences you've seen of how the emotional experience ends up making it so that the engineers are unable to converge on a shared meaning of better because the emotions are get in the way.

JOHN:  I certainly have a direct example of that in my life. I think I mentioned this on an earlier show last year where I had rewritten a piece of our code to account for some new requirement and pushed it out and said, "This is way better," and then I think like two or three months later, another developer had other work to do that impacted this code and then rewrote that to take into account what he needed to do.

I read the pull requests and I got really pissed off because I was like, "This has only been in production in two months. Come on," and like, "Destroy all the work I did," and fortunately, I was able to not express that to the other developer because I knew it was just my own reaction to what was going on and further thinking about it, I realized that when I had originally built that code, I hadn't actually consulted the rest of the team on what all it needs were and so, I had left out what his project needed and so, he had to rewrite what I had written in order to account for all the other things that need to happen.

Emotionally, if I hadn't been aware of that, it probably would turn into a big thing because I'm like, "What the hell are you doing? Your crimpling all over my stuff," whereas the actual mistake was my own and not bringing enough input before, just charging ahead and building my own solution.

BRYAN:  I feel like code maybe relatively unique in that is something you build them and put together with a lot of effort but can be changed so easily, so that's not as true for physical things that you've built or like a motorcycle for example, if you do a certain fix on its engine, somebody is not going to come to totally change how those fix happened.

JOHN:  Yeah or even creative things like writing or painting. Writing a little bit, you may have an editor like rewrite a paragraph but it doesn't keep happening over and over again over --

BRYAN:  Not to a certain extent.

JOHN:  And certainly people don't come in and paint new additions onto your canvas but I think a lot of us relate to our code in a similar way that you would do a painting like, "This is mine. I really poured myself into this."

BRYAN:  Yeah, something you put a lot of thought and effort into and produced and put out into the world.

JANELLE:  That's really interesting like as an art, we've got this really fascinating challenge of collaborative art where we were doing a painting or an art project that normally is hard to have multiple people working on because we have all these opinions about quality and better and want to express our soul in this thing, right? But we're having to figure out and mature as an industry to kind of put all that aside, grow beyond that, such that we can do this collaborative sculptural art project together and build a sculpture of ideas. I was going to say that these projects, the reason why we have to collaborate is it gets huge.

We've got coordination between hundreds, thousands of developers sometimes and it's really quite incredible that we've been able to do that, given that there's this undercurrent of emotional, artistic creation of beautiful, romantic, passionate side of software development that is very real and we've had to mature a lot, I think as an industry to be able to kind of set all that aside and go, "We've got a job to do." It's kind of cool.

JOHN:  Yeah. It's interesting. I haven't really worked on any big collaborative art projects but I would imagine that there has to be some sense of giving up ownership and that deep identification with the art you've created in order to collaborate effectively with someone you can't just all be fighting to do your own painting. That's one aspect of working on software but then, you have the additional things where there are objective or measures of quality such as does it work? Does it perform? There are all those also mixed in which I think is a new situation for humanity. Certainly, it doesn't seem to be a lot of literature on over the last 1500 years on how do you combine people working together up to the thousands of people and have them communicate art and not bring in ego and also, we meet objective goals and have discussions. I think this is such a young industry.

BRYAN:  Yes, how should the individual contributors think about, so that the group is moving in the right direction and their own emotions and feelings about their work are healthy.

JANELLE:  I guess the thing I'm seeing in this discussion is that it is young. At the same time, what that means is the insights that we develop in the context of software development, in the context of having to bridge this gap of art in a way, in this romantic paradigm and this classical view and this component and functional, we need to get the thing out the door.

In our industry, we have to face this challenge in order to do our jobs and you see the emergence of certain kind of behavior patterns, certain kinds of collaborative practices of setting it all aside. The skills we've developed to be able to have these conversations about these things are kind of cool, are cutting edge in a lot of ways because of the uniqueness of software as a form and really being the bridge of these two things kind of coming together.

JOHN:  Yeah. It's interesting. I think at the beginning, you're talking a little bit at an even higher level, sort of beyond the software industry into the world and politics and things like that and what's occurring to me is often the word used to describe the differences between, say political parties, that there are differences of value systems, that you value different things but I think that leaves open a trap door, which is that you can believe that one value system is better and one is not better.

But if you instead think of it as these are systems where they're working on a scale that's trying to approach the same sense of quality from different angles, that it's much harder to say one is better than the other because they're both attempting to do the same thing. They're both attempting to reach that point of quality that doesn't fit with your spatial metaphor, Janelle if it's with mine, though.

BRYAN:  The thing that keeps bouncing around my head now is the point about how in software we have objective measures of quality of like is it responding fast enough? Are you hitting a certain SLAs that the business needs to stay in business. But then there's also these much more subjective measures of quality like readability and the other things we've mentioned. I guess I'm trying to think of examples sort of unique situations of balancing both of those or some interesting consequences of having both of these in the systems that we're working on.

JANELLE:  I think one of the things we've done is to take these more subjective, romantic ideals around readability and go, "What effect does this really have on the business? What effect does it really have on the team?" and to try and bridge these things together to kind of step back and go, "What is it we're even aiming for? What does better really mean?"

In a software context, when we can kind of zoom out and have that abstract conversation, we can end up converging on a definition of better and I feel like if we did the same kind of thing, as opposed to going, "We've got two conflicting value systems," and then we're arguing about all the stuff, all of the means of optimizing for these two different value systems. If we just stopped the whole discussion and took a step back and went, "What does better really mean?" If we want to make the world a better place, forget about all the means of getting there, forget about all the strategy for a minute. What does a better life? What is well-being? What does we even want in life?

If we erased all of this stuff and could dream up any reality we wanted to, we could live in any reality we wanted to. It's just software and we can just throw away and rebuild it. Let's just pretend for a minute that we can do that. What does we even want? What is quality? What is quality look like? And maybe if we could agree on those things, if we could agree on what better means, such that when we try out different ideas, try out different strategies, we can judge as to have a shared agreement on, "Is this experiment working out better?"

Maybe if we could come up with a way to agree on those ideals to take a step back from that conversation and talk about better, talk about quality, that becomes a bridge to set all our differences aside of these two different sides and come up with a shared arrow really. It's an arrow.

BRYAN:  This keeps reminding me of some of the measurements that have come out of the devops world where you want to be measuring only team statistics versus individuals statistics and then I also wonder if teams that have these sort of measures of quality, like measures of performances, a common word in software maybe, are these set up made explicit to the team and everyone agrees? We are working on these measures right now versus teams that do not have anything set, then you get like, "We have the whole team working towards these three or four performance measures," and then little differences of opinion and exactly how to write this kind of 'aren't center stage anymore' versus teams that don't have those three or four measurements they're working towards. The individual differences and differences of opinion or differences of subjective measures and quality, it becomes a much bigger, more difficult, more emotional thing because there is not this [inaudible] working towards.

JANELLE:  That's a really great point.

BRYAN:  So this idea of we are agreeing on these three or four things is almost a distraction to the issues that don't matter as much.

JOHN:  Yeah. You could have some of the bikesheds.

BRYAN:  Exactly. I don't know if there’s any research on this or any data but I'm wondering about the differences between teams like that.

JANELLE:  Yeah. I am thinking about a team where I worked on where we actually wrote a team charter manifesto type thing that was like, "This is the scope of what our project entails. This is what we care about. This is what we're working toward, what better means to us that we're going to focus on," and then once we agreed on the scope and the arrow, a lot of discussions and arguments and stuff and all the emotional stuff went away because it was made explicit. It wasn't this undercurrent of disagreement of conversation underneath all of the things that were actually happening. It was this constant tension.

We put all the things on the table. We had an explicit discussion about it and we agreed on the scope and the arrow for our team and then everything we talked about at that point, we have a reference point to go back to. We're having a disagreement about what to optimize on all of these different dimensions and choices of things. Well, what's the thing we want to focus on for our team, you know? And we agreed on like this is the direction we're going to go and it just level set all discussions because we made those things explicitly and wondering if we get apply the same ideas in other contexts.

BRYAN:  I wonder if good size has a big effect on this because software teams, it's often small enough group to be able to choose a handful of things they're working on but if we're talking to the level of a country, it's just almost certainly not going to happen because it's too big.

JANELLE:  I think about things in software, the impact of the bigger group. It's like we get off into the realm of politics and there's so much baggage with the existing system and infrastructure and so I want to stay and thinking about just cultural influences of things because at the end of the day, there's just this level of emotion and trying to control things and all these dynamics that are part of the existing status quo.

If you come back to software where we've got this context that there's a lot of collaboration, we've had these open source movements and these Agile movements. What happened to keep these things off is essentially a group of people that got together and wrote a manifesto and said, "Here's the thing that we believe in a direction of an arrow and a scope that we care about and we believe this is the way that we ought to go." We have the Agile Manifesto. These are the things that are important that we're going to work on and collaborate on as an industry and it didn't take someone giving those people permission to go, "We believe this is the arrow of better and this is the way that we're going to go and work toward," and to some extent, that's all we really need -- write a manifesto. This is a direction of better that we're going to work toward in our everyday lives, in our teams, in our families, in our interactions with other people. We're going to put people before process. What does that mean? What does that mean in all these different contexts?

You saw this movement, this change happen across our whole industry that has been huge, that has affected millions of people that started with a few people writing a manifesto and going, "This is an arrow that we think is important and we're going to stand behind this definition of quality."

Do we want to go into reflections? How do we want to wrap up this show?

JOHN:  The whole show is kind of a reflection.

JANELLE:  Yeah. I was trying to kind of tie together some of these things as how these ideas apply between different themes and I feel like the thing that I wanted to come back to is the main point of the show is the quality that taking a step back and looking at the shared definition of quality, gives us a way to bridge these things. It's a mechanism of creating bridges and whether we're talking about bridges in a very localized context or bridges in a higher context, that practice of taking a step back and going, "What is quality?" it can potentially solve a lot of problems. It just that simple, first principle.

JOHN:  Yeah. I think you're right with that.

BRYAN:  One of the things stressed in the book was after the initial description of the romantic view versus classical view is a couple of paragraphs about each side sees each other wrongly and how much of a problem that is. I think a lot of the book is a comparison between author's current self and the author's past self and how different they are and they eventually at the end of the book, it seem to find a middle ground or at least the author's present self reconciles all the differences between himself today and himself previously and try to tie it back to that because we've been talking about groups of people whereas a lot of the discussion of it was one person or one person now and before.

JOHN:  There's actually a quote in the book that I highlighted because it actually brings up this very thing that we've been talking about. He says, "Actually, the root word for technology, 'techne' originally meant art. The ancient Greeks never separated art from manufacture in their minds and so they never developed separate words for them. I feel like that's what we're talking about here with software, where there is art and there is manufacture and that is sort of classic and romantic have to be fused into this one thing that we're talking about.

I think what Janelle, you're also talking about, about the bridge is taking the different value systems, the different arrows and fusing them together in some degree or at least, getting people to agree on common one or one that's a little bit higher level that can then help unify the group into a single direction, a single set of values. I think that’s an incredibly powerful thing and I think the difficulty comes, like as you said Bryan, with scaling it up, like how big a group can you get to do this thing?

BRYAN:  I think the biggest takeaway for me though is when you recognize you have two different categories of measures of quality, the team starts to need guardrails to push the group towards just a couple of agreed upon things and recognize that all of the subjective differences are never going to go away like build up a system where those sections can happen and it's easy to keep moving on towards the next step.

JANELLE:  It's interesting, the subjective discussions never really go away and as opposed to thinking that they ever will go away, that we can somehow argue our way to completion, I think we need to start with the premise that the discussion is continuous, the understanding is emergent, that clarity is always increasing and there's this process, this flow of working out mistakes and misunderstandings but it's always moving. It's never certain. It's never still. It's never done.

In the context of software development, we have to figure out how to bridge and fuse all these different arrows with as classical paradigm of focusing on function and composition and this romantic paradigm of art and techne and this invention of technology and all the things involved in human communication bridges and subjective feel from what is better.

In this collaborative, artistic context, we've come up with ways to build bridges. We come up with ways to organize larger and larger groups of people that start with something small, that start with taking a step back and asking a question, "What does better really mean? What is quality? What are our different definitions of quality?" and as opposed to feeling like we can answer that question, maybe the point is just to ask the question to keep asking the question, to let the answer be a continually evolving thing and that we can clarify these bridges by letting the bridge itself be continuous in a way, by letting the bridge be defined in terms of a question, to always be asking, "What is it we're aiming for?" and when we think about our emotions being in this mix, what is it that I'm attached to that potentially is making me blind to what's going on out there.

JOHN:  Yes. Something that occurred to me just a little bit earlier in what you are saying is that much like devops is a process and not a state. This process of continually integrating viewpoints and aligning value systems is a process and not a state. It's not like you did it once and then you're done and you don't have to worry about it anymore.

JANELLE:  Yeah.

BRYAN:  Sure that understanding is very hard. I almost have to go with that, explicitly said.

JANELLE:  It's very hard and it's also unending. It's continuous integration.

JOHN:  Yeah. Continuously integrated value systems.

JANELLE:  Yeah. Continuously integration of value systems, continuous integration of quality and maybe, this is the next era of our industry and next meaning of continuous integration is having explicit conversations about what is quality and continuously letting this definitions evolved by making them explicit if you start thinking about this and this is essentially science, right? What is science? It is this continuously improving, continuously integrated definition of this arrow of things getting clearer and clearer but towards a certain purpose, towards a certain meaning value of what it is we're optimizing for. It's like it doesn't exist in a vacuum.

I think maybe that's the point of these two paradigms is the components, the breakdown of all the things, it doesn't exist in a vacuum. It's like if we're not anchoring to something that's real, that has meaning outside of all the boxes, it just becomes vapor. If the thing I ultimately care about is, "I want to be a happy engineer on my team," that is ultimately the experience that affects me every day because I want to have fun. I want to love my job, right?

BRYAN:  That said a lot. I think the next time my team has a retrospective, I'm going to call it a value system and see all the meaning.

JANELLE:  I like that.

BRYAN:  Seeing all the forces at play on the software teams that I work with as being in two categories: one that fits a classic and one that fits the romantic. We have lots of processes and direction around how to handle those kinds of constraints but not so much on the romantic constraints. There is a lot of work around retrospectives and doing one-on-ones and stuff like that but I feel like I'm thinking about it from a different perspective now. I think the [inaudible] example is really an eloquent way to state that.

JOHN:  Yeah and for me, I think a metaphor came to my head sort of halfway through and I wasn't quite sure when to mention it but I was thinking of in computer vision processing, you have these things called edge detectors that will find where the border of something is and I want to try and thinking of building up my own skills as an edge detector for detecting these value system edges, where there's two different discussions of quality but they're talking on a different scale and being able to make those visible, so they can be reconciled. I think it would be valuable.

JANELLE:  I so love that, as brilliant idea -- edge detection of value systems. If I think about my little gravity ball metaphor like what are these different gravity balls, you could think about where are the different edges of these different gravity balls that are out there of what is quality and how do we merge these things together and have a continuously integrated definition of better, that we're always evolving together.

I think my biggest takeaway here is the power of making these things explicit as a way to shift the conversation and that if we take a step back and ask these questions about, "What is better? What is quality? What are the different paradigms that we're looking through and how can we bridge those together such that we can see each other through these different paradigms such that we can put all our emotions and identity stuff aside and be able to come together and work together as a team, maybe the answer for getting there is a simple as writing it down. As a start point, just start and write it down. Start a conversation with your team. Maybe that's where we start.

All right. This was a really great discussion. Bryan, John, really great talking with you. I hope everyone listening had a really interesting time listening to the show as well and check out the book, Zen and the Art of Motorcycle Maintenance by Robert Pirsig and have lots of really great discussions with your friends. Thank you for listening.