DevOps’ sister site Digital Anarchist has launched a bi-weekly video series and companion monthly roundtable on DevOps, Automation, CI/CD and testing. Featuring leaders in all of these areas, we explore the challenges and issues software delivery and IT teams face every day. How do we go faster, smarter with better quality? DevOps Unbound!

Transcript

Alan Shimel: Hey everyone. Welcome to the very first episode of DevOps Unbound. I’m your host, Alan Shimel and joining us for this initial episode of DevOps Unbound, I’m proud and happy to introduce you to James Bach and Grigori Melnik. Grigori, James, welcome to DevOps Unbound.

Grigori Melnik: Hey everyone.

Shimel: Before we jump into things, let me give each of you an opportunity to kind of introduce yourselves, your backgrounds, your positions, etcetera, so that our audience kind of knows a little bit, if they don’t already, who you both are. So, Grigori, you’ve already been a guest in our show, so if you don’t mind, I’m going to ask James to go first. James? Introduce yourself. Go ahead.

James Bach: My name is James Bach. I’m a consulting software tester. I started as a developer in my teen years after I dropped out of high school. I’m the proudest high school dropout you will ever meet. I later wrote a book about dropping out of high school and my particular self-education method, but my big opportunity came when Apple computer hired me to be a test manager, and at the time, I was the youngest manager in the R&D division of Apple computers.

So that’s kind of something I’m proud of. And I fell in love with testing and I decided to devote my career to testing. I studied the epistemology of testing, the mathematics of testing, the sociology of testing. I am a bit obsessed with testing.

Shimel: To say the least.

Bach: And I have a book about that called “Lessons Learned in Software Testing” with a couple of coauthors. And now I teach and consult.

Shimel: Excellent. And you know what, high school dropout or not, you’ve done pretty darn good, so congratulations and not saying it’s an example for our younger people in the audience to necessarily emulate. Of course, James grew up –

Bach: My son did better than me. He never went to high school, so I’m –

Shimel: Really?

Bach: He’s already outdone me.

Shimel: Absolutely. Very good. Grigori? Why don’t you tell them a little bit about yourself?

Melnik: Sure. So I’m Grigori Melnik and I am the chief product officer of Tricentis, focusing on building the testing tooling of the future, testing tools of the future. Previously, I guess I spent almost two and a half decades focusing on the developer audience and building all kinds of platforms, Microsoft and Splunk and MongoDB and you know, always been kind of customer obsessed in the sense of developer obsessed quite a bit, making sure that whatever we were focusing on would help drive the productivity and alleviate some of the pains that developers in our target audience had.

And while a few of those things that I’m particularly proud of, my team at Microsoft was actually the first one that built the very first auto-scaling for what was back known as Windows Azure, now Microsoft Azure, but also focused on common patterns and practices in implementing the crosscutting components that represent crosscutting concerns that later would make into the .NET framework.

So again, a lot of work identifying those patterns, capturing them, externalizing them, testing them out and then helping drive their use. When it comes to testing, I first kind of discovered it in my days in academia when I was doing research and teaching at university, and it was quite interesting because testing was predominantly viewed through the lens of formal method groups. It wasn’t really viewed as an intellectual activity of discovery, as an intellectual activity of exploring or experiencing something.

And those were actually the days when I’ve encountered the group of testers from the context driven school of testing, including James and then we kind of kept in touch ever since, even with me gravitating away from the testing more into the developer world and now doing like the full loop of coming back to testing and I have to tell you, I felt, when the opportunity came, I felt that the world of testing, at least from the perspective of how the discipline itself has advanced would be way further developed in the last decade than I found after kind of leaving it for a while.

So I’m now on a mission of kind of reigniting that whole discipline and putting it more on a pedestal and giving it more view and empowerment and leveling up all around. So, yeah.

Shimel: Excellent. So, thank you both, gentlemen. And I’m Alan Shimel, I’m the editor in chief, CEO for MediaOps, the folks behind DevOps.com, Container Journal, Security Boulevard, TechStrong TV, et cetera. And just quickly before we jump into today’s agenda, DevOps Unbound though, today’s focus is on testing. It’s not just about testing. It’s really about DevOps kind of unbound, setting us free, being able to leap tall buildings and bound into space, sort of freeing ourselves of gravity, whatever you want. It’s about speed. It’s about acceleration. Right? It’s about automation in a lot of ways.

And each – we’re going got be doing these every other week and each episode will focus on particular aspects of this unbound nature, if you will. Today’s is testing. And then once a month, we’re also going to have a roundtable with about six or eight people of Grigori and James’ stature and we’ll open it up to the public for live audience questions and discussion. So I’m really looking forward to that. DevOps Unbound is sponsored by our friends at Tricentis and we thank them for it and with that out of the way, let’s jump into things.

So, Grigori, I wanted to start off – obviously, you and James take very different paths to our – and both of you have been very successful in your lives and careers. So it just goes to show, there’s more than one way to skin the cat. Right?

But, let’s take a look – look, I’m probably older than both of you, though not that much I’m sure, but let’s look at the history, the historical context of where you guys come from to be sitting here today and how that, you know, vis-à-vis kind of the whole testing industry, the whole testing, you want to call it a profession, the guild, the whatever you want to call it, right, how has this evolved over the years and let’s put some context in with timeframes. James, when you first went to Apple without saying you’re old, what kind of – what were the timeframes for that?

Bach: Well, I am old.

Shimel: So am I.

Bach: But you’re older, which is nice. It’s nice to be a young guy in the room again.

Shimel: Uh-huh. I can’t tell you how well that makes me feel, but go ahead.

Bach: First, 1987, May 21, 1987 was the first day that I ever professionally tested something as a tester. Before that, I was doing videogame development and I had done informal testing, and I hated testing because testing just got in the way of me shipping my product. So, I didn’t like testing until it became my job and then I realized I’m perfect for testing ’cause I love complaining. And I’m much more interested in finding how things don’t work than to figure out how to make them work.

Shimel: That’s interesting. You know, my background’s in cyber, back then we called it InfoSec, and in InfoSec, most of the people got into it ’cause they liked to break things. Right? Yeah. Same thing. Grigori, how does that timeframe-wise and everything else, how does that match up with your own experience?

Melnik: So I like to actually build things. _____ you guys who are breaking things. And occasionally I break things and actually this also speaks about this overall I guess optimism of most developers who think that what they write is perfect and always underestimate the amount of buggy code that we put in there.

But to me, if I think about my first day when I actually had my job as an engineer, actually, it was September, I think 5, 1990, so a few years after James and at that time, I was actually writing a C-library for a PC converting the data from mainframe into the visual format and I had to deal with all kinds of quirks of Fortran and the 80 characters limit and the asterisks for, you know, for bringing – the continuation of the line, all kinds of exciting stuff. But back to the beginning, to make sure that I don’t go too far on the tangent, we actually didn’t have, for a very, very long time – again, I’m giving you my angle into the testing, if you will.

We actually didn’t have a dedicated thinking about testing as an activity, as a pursuit of excellence. It was just something that you kind of were doing and then at some point later, you’ve heard and learned that oh wait, look, there’s a QA department, apparently, right? And they’re the ones that were mostly viewed as gatekeepers or police of some sort. Right?

And then again, if I think about again, once I got more into the research and academia and studying testing specifically because, you know, I’m probably one of the very few people who has testing in the title of my PhD dissertation. But, I remember looking back and thinking, “But where does this come from?” Right? Where did actually software engineering come from?” Right? And of course, this is where the history of the conference deck, you know, after the _____ _____ where all the stalwarts of at that time computer science and well, not even computer science, mathematics departments because that’s who were doing all the programming back then at the point the software engineer discipline and later on the association of debugging, right?

It was the infamous story of how the moth was found in Harvard University’s scientific lab and the term bugging, you know, was coined. I almost think like the – in the early days, it was very much associated with this era of debugging. Right? Then later on, the era of the ability to demo, the fact that the software was matching the stack or the requirements, I think it almost feels like there were at least a decade when people were fixated and some would argue that it still continues.

Shimel: What decade was that?

Melnik: Hmm?

Shimel: What decade are you referring to?

Melnik: The debugging or the – the debugging I’d say –

Shimel: Are you talking about the 70s? Are you talking about the 60s? Are you talking about the 50s?

Melnik: I’m talking about 50s and 60s. I’m talking about the 50s and 60s as almost the era of debugging the way I viewed it. Then, after that, the era of more like 70s and 80s where you were focusing more on matching the spec and demo and that the software would actually approve it. And this is where this big, big, big focus was on formal methods and trying to even mathematically prove that a software worked according to the spec.

And then after that, I feel like the next era was the era of breaking or, you know, something that probably is still continuing. And again, all these elements I feel are present in today’s profession of testing, but the later years, the last 20 years was everything that I was kind of studying, watching from the sidelines, getting myself into. I like to call it the era of enlightenment, if I may. I know that’s super pompous of me, but this is where I view more testing in the way how James and other members of the context drew in school of testing had formulated it which is, you know, lighting the way for the decision-maker, not for the developer necessarily, not for – again, it could be for the developer, but somebody who at the end of the day makes the decision whether what is being produced is acceptable or not, or if it’s good enough to ship. Is it, you know, what risks associated there and informing me as a decision maker about all these different factors and then leaving that decision up to me.

So the testers are not the police. They’re not the quality gate. They’re not _____ anything. It’s really up to the stakeholder who is commissioning all this effort and who makes the ultimate decision about releasing something, putting something into production.

Bach: I’d like to offer some historical notes on this.

Melnik: Please.

Bach: Okay, first, are you aware what the first book was on the subject of software testing, the first known book? A little quiz for your Grigori?

Melnik: Is it the Myers book?

Bach: It’s before that. It’s Program Test Methods from 1972 by Bill Hetzel. Now that book was a report on a conference a testing conference which was the Chapel Hill conference, which happened in ’72. That seems to have been a historical watershed event in testing. Before that, the first chapter on software testing that I’ve been able to find was written in 1961 by my teacher, Jerry Weinberg, who wrote it when he was 25 years old. It’s a brilliant chapter on testing.

What’s fascinating to me is how differently Weinberg talks about testing in 1961 compared to how they talked about testing in 1972, although there is a reference in the 1972 book back to Weinberg, praising Weinberg’s attitude about testing. It’s fascinating to read that because the book in 1961, it’s Computer Programming Fundamentals and the chapter about testing was written by Jerry, he told, although it said it’s co-written, the book’s co-written with Herbert Leeds and Jerry Weinberg, but Jerry wrote the chapter on testing.

And Jerry talked about testing as a matter of imagination, not automation, as a matter of being suspicious and critical, as a fundamentally unalgorithmic process. And he develops this beautiful story in his chapter about a programmer who’s sure that he’s found the last bug and then finds out that he’s wrong. And then he adds another check for that.

And then he’s sure now he’s found the last bug and then he sees something else go wrong. And Jerry’s conclusion is look, this is just, we’re working on complex systems and this is always going to be like this. Now, Jerry was on the first project in 1958 that ever had a dedicated test team.

Now, the reason why he knows that is that in 1961, IBM held a conference of all the computer programmers in the entire world of which there were 400, apparently, and Jerry said his team went to that conference. He was at IBM at the time, and he said everyone thought they were crazy ’cause they had a dedicated group of testers and no one else did.

They all were just testing their own stuff. So it seemed like the idea of having a dedicated test team caught on and then in 1972, the way they talked about testing was all about test cases, automation, formality and that kicked off the era, I think, of the factory, the test factory. We can have technology and we can have procedures that make it so you don’t rely on human thinking.

So this goes against what Jerry Weinberg was preaching, not only back in ’61, but all through his career, I became a student of Jerry’s in around 1989 and took all his classes in the mid-nineties and he became a mentor to me. That’s why I’m a real acolyte of Jerry Weinberg, because he always put the human in the center of everything. But, testing – when I joined testing, all the testing textbooks were about how you have to define test cases and if possible, automate them.

And I felt like that was a fool’s idea. I think, well, the problem is is that there’s too many things to define and far from being unbound, we’ve become super bound by all of these documents and all of this code. And so if you want to be unbound, we have to find a way to temper that. We have to find a way to interact with our tools so that we’re not constrained too much by them. And that, in the nineties, the urge to unbind ourselves from that waterfall world and that heavy documentation world created agile, but it also created the context driven school of software testing, which is a humanist approach to software testing.

And that was in the mid-nineties that we started creating that. And then DevOps and agile continued to sort of take over the world except that it seems to me that agile in a lot of places has lost it’s humanist foundation and it’s turned into tools, tools, tools. And so if we’re going to really talk about Unbound, DevOps Unbound, it seems to me that we have to be specific about what is it we’re unbinding. I hope what this means is it’s people being unbound, using DevOps as a tool rather than –

Shimel: But not just a tool. I’m sorry. I didn’t mean to jump in. But not just – you know what, James, we don’t want to make the same mistake that Agile made. And you just said, one of the problems with Agile is we went from humanist to tools, right, too much of a reliance on tools. Let’s not make the same mistake in DevOps. I think that’s something I’ve advocate for for a while too is we can’t lose the human in DevOps.

Bach: Actually, I want to hear you say more about that, Alan, if you’re willing to say a little more about that.

Shimel: I’m not shy. I’ll give you my two cents. Look, I started Devops.com. I cover this place. I cover this area pretty heavily and I have for seven or eight years now. And I think there’s been this – and I don’t want to say agile failed ’cause agile is far from a failure. But there has been a reliance on tools and maybe overly processed. When we think about things like ITIL and ITSM versus DevOps, let’s say, right, we get in – we tend to point fingers at ITIL. Excuse me and ITSM _____ too much process, too heavy, too much of that, that whole change management thing.

But there are good things there. Nothing’s all bad and all good. The world’s not black and white. It’s grey. Right? And so there are things we take out of ITIL and things and ITSM that we put into DevOps. Btu DevOps, to me, anyway, and it’s just my humble opinion, is fundamentally about people and teams and culture, not the tools- there’s a lot of tools we could use and there’s overlap in tools and what’s the best tool for any given job.

We could fight about it till the cows come home, but at it’s nitty-gritty, DevOps is making sure that devs and ops and tests and security and these people work with a higher degree of communication, right, with a higher degree of cooperation getting jobs done faster. And we do that by adding things like automation to the mix. But automation for automation’s sake alone is not enough. Right? And to do automation, yes, you’ve got to use tools sometimes to make that automation work. I get it. But if we lose the fundamental aspect that DevOps is, at its core, about humans, I think we all – we lose what DevOps is and I don’t hold myself out to be as accomplished as either one of you, but I –

Bach: I still love you, Alan. I love what you just said. I think this is – if you can hold on to what the principle and the feeling behind what you just said, we can do anything with tools and we’ll be okay. We’ll be okay. If we’re talking to each other, if we’re caring about each other, I keep seeing people losing that and of course, any technology and any methodology, when it’s applied sociopathically, will become abuse. And so we just – those of us who can, shall do – should do whatever we can do keep it non-abusive and keep us talking. And then I think DevOps can be a wonderful thing.

Shimel: Absolutely. I’m sorry to take us down that. Go ahead, Grigori.

Melnik: No, it’s super encouraging to hear what you said, Alan and again, I’m a very big believer into the greatness of human mind, but it feels to me that in this kind of history of our industry, the pendulum keeps swinging back and forth, right? remember the whole infatuation with the case tools, you know, back in the eighties and nineties and then later on, there was this whole big movement of the software factories, like the term was actually software factors where the idea was that you can go and abstract away at some high level and then the loop, y, the tools will generate all the code and everything for you and make it all highly maintainable, all that, and of course that failed too.

But I think out of this desire for some reason to do – to come up with the sort of boosters. So I don’t know, some kind of the way of equipping the humans to deal with the inherently complex problems where today there’s no better mechanism of dealing with them other than human brains. So this whole vision of, you know, computers writing computer code, I mean, that’s been promised in the first era of AI, not today, but I’m talking about the sixties, right, and seventies were all –

Shimel: Yeah, yeah, I mean Spielberg does pictures.

Melnik: Then it kind of died out. Right? Same thing again, you know, having the computers entirely come up with the test strategy, the thinking about testing automatically, entirely automatically, I think is – I think it’s utopical, at least if you think about what the tools are capable of doing today and for a very, very long time in the future. I think the human will remain to be at the center of this activity, while again, all the tooling is great because tooling gives you additional powers and additional ways of perhaps automating the most rudimentary, the most, you know, boring elements of the job and lets you actually free up time to think about new theories, new hypotheses, new models, new approaches –

Bach: But you’ve got to consider different kinds of tools. Like, have you noticed the difference between let’s say a tool like a programmer’s IDE. When I use a programmer’s IDE, I don’t feel oppressed. I feel empowered. I feel like I’m riding a magic carpet and I have laser cannons mounted on it. I feel wonderful. But when I use most testing tools, I feel oppressed, like I have just a few possible things I can do and if I have any –

Shimel: Like you’re castrated.

Bach: that’s outside of what the test tool designer has thought that I might want to do for testing, then I’m not allowed to do that. This is what I feel like when I encounter something like Cucumber, which is very restricted and the Gherkin language, it’s very restricted. It’s stopping me from going on flights of imagination. And yet, when I use the tools that programmers have created for programmers, unsurprisingly, programmers have created for programmers tools that make them feel powerful and free and able to do all kinds of wonderful things. I would like to bring the same sense of freedom to testing that programmers already enjoy. That’s part of what we’re doing with the transformation work we’re doing at Tricentis.

Shimel: Yeah. I love that.

Melnik: In all fairness, not all of the programmer’s tools are that liberating. Some of them feel like you are operating in a straightjacket too, but in general, at least there are some examples, there are instances of tooling that are widely accepted, widely adopted today that are supporting and kind of accelerating your abilities to do your job without constraining you. That’s for sure.

And you know, the piece that James was alluding to, this is actually the new initiative, that we are driving inside Tricentis, you know, about mentioning this whole new platform of the test tools for the future where we are building something akin to the IDE, we’re actually not calling it IDE, we’re talking ITE, integrated testing environment where actually it’s the human being, the human tester who is in the very, very center of the ITE, and all these other snippets and utilities and services and everything around the human tester, around the human that manages to support the individual in the way, wherever his line of thought, line of exploration, line of test execution may lead to. Okay?

So yeah, we’re kind of envisioning this to be as a super configurable kind of morphing tool, almost like the chameleon style. We’re depending on the context and the environment, the different capabilities of the ITE, the integrated testing environment will represent themselves and then the human will actually pick whether this is actually something that they want to take advantage or not as opposed to again being forced into a specific kind of mold or one way of doing testing. And I don’t think – we don’t think actually anybody has attempted something of this caliber, specifically in the space of test tooling before. That’s why we’re so enthusiastic and so passionate about this project. Aren’t we, James?

Bach: Yeah. I also don’t think that anyone is going to be able to copy is easily because the only way that they could actually compete with us is by hiring someone who loves testing, which test tool companies hate doing because testers are troublemakers. I still can’t really – it’s hard for me to fathom that Grigori really knows what he’s done by hiring me because I’m a constant gadfly.

Melnik: [Laughs]

Bach: I’m constantly complaining about the state of test tools in the world and at Tricentis, frankly, and I want things to be fundamentally better, but that means we have to fundamentally change how we think about what is a tester. Which might get us into the role of testing a bit, but the – to me a tester is a puzzle solver, a problem finder. I’m not a button pusher and I’m not a verifier. I don’t verify things. Tools can verify things. I’m not looking to prove that something works because I can’t prove that anything works. What I can do is collect evidence and then draws inferences from that evidence with a critical mindset.

And of course, lots of tools are collecting facts about the products that I’m testing and those – that can be automated and so we’re pulling in these facts. And we can say, “We got this output and we expected to get this output, so apparently there’s no problem here as far as we can tell so far.” But then the tester layers onto that a critical mindset saying, “But how do we know and how can we be fooling ourselves?”

And so I’m bringing that mentality into Tricentis and I’m really surprised so far they’ve been actually quite welcoming of me, but for years and years, I’ve tried to help other tool companies with this and basically, you know what reaction I get? They basically say, “Well, our customers just want to have automation that just pushes a bunch of buttons and we don’t really care about test design. We don’t really care about empowering testers. So that’s not going to help us make any money, James, so we’re really not interested in supporting the skilled testers that you keep talking about.” So Tricentis has a different kind of vision that I think is hard to match.

Shimel: There’s also a little bit of you can’t make wine before it’s time. Right? And I think right, I think you need the right macro conditions, that things like DevOps have brought about and the whole progress -0 we’ve gone back here now to the fifties and sixties and all the way to the present time.

Certainly the world we live in today may be a – I want to think so anyway, we’re a little bit more open to the idea of saying, “Look yeah, we can automate some stuff. We can have – we don’t need a human to just push buttons. Right? We have tools that can go push the buttons for us, but we need humans to do blank. We need humans to do some of this stuff and so we need to enable and empower them to do that within the context of let’s automate what should be automated, let’s say. But we still need those humans in there.

You know, when I was growing up, much like you guys, right, the only animal in the world that used tools was humans. Isn’t that – that’s what I learned in school, right, that’s what separated us from animals, one of the things, right, was our ability to use tools. Well, then we found out chimpanzees use tools and other monkeys use tools and we still were okay with that ’cause they were primates. Now we found birds use tools, right, to crack nuts and stuff like this.

So tool use in itself does not connotate one’s intelligence or higher being. We need to – so to me, that’s the ultimate case. Right? It’s not about what tools we use. It’s about how we use our brains. And I think that’s apropos to what we see in testing today. Yes, we could come up with tools, but it’s creating an environment for people to think in and use their brains in and apply it that I think will ultimately provide us the highest payback, if you will. Right?

Bach: It’s interesting what you just said about you’re implying that the history of how we got to where we are now is important, that we have to have a certain set of – a certain historical context, technological context in order to take the next leap. And I think one thing in which that’s really true is we now have decades as an industry, decades and decades of experience trying to eliminate people from engineering and we can’t do it. I remember, maybe you do, there were these advertisements in Byte Magazine in the eighties about case tools and all your marketing people can just define your product and you don’t need developers anymore because it automatically generates all the code.

And I remember sitting there at Apple Computer reviewing case tools, advertisements that had been sent to me, thinking, well, could I buy some of these tools and actually use them to help with the testing? And it turned out, no. You couldn’t. It was just all – it was all hype and nothing. And so I shrugged. And so a lot of – and even today, now we have AI, AI is the new case tool and the AI will do all this stuff for you. Then it turns out the AI is biased and racist and confused and if you put kitten ears on a whale, it says, “That’s a kitten.”

Shimel: Yep. And it’s no more than ML, the machine learning anyway, but you know, yes, we’ve been – we have been, you know, chasing this white whale for most of my adult life and at the same time, if it was a nation, the fastest growing nation on earth are developers. There’s 40-something million is the estimate growing what, 20 percent a year or something like that. So I think it’s time we stop probably chasing that white whale and move on to empowering people.

Bach: And one way to do that, I suggest a definition of programmer or perhaps developer. And the definition I use is a developer is someone who stands at the gateway between the world of the machines and the world of humans. And the developer’s purpose is to operate competently in the world of people and then operate competently in the world of machines.

And if you don’t have that person standing at the gateway, then you don’t have a connection between the world of humans and the world of machines. You just have people kind of praying to the god of technology and hoping that good things happen. And so no matter how complicated technology gets, no matter how much AI we have, we still have the need to operate competently in the world of people and the developers will always live right at that threshold. And testers need to live there too and not get mowed under by automation.

Melnik: Yep.

Shimel: And you know what guys, we’re almost out of time, but this also brings up something that I thought we might be able to get to on this show, but we’re running out of time, and that is that this caste system, if you will, caste system of developers being a higher caste than the tester who’s higher than the, what we call today the SRE, the ops person or what have you. And this whole IT stack of humanity, I think we need to examine that too with the develop – when we’re asking the developer to do the security and the testing, is he any better than the tester? Is there a difference? But we’re going to save that one I think for another show, if you guys would like to come back on, and we can explore that a bit.

Melnik: _____ back, but I categorically reject that whole hierarchy and I also do not like the whole, you know, notion when people say, “Hey, but the tools and everything that would really help with the low skilled tester.” That’s another notion that kind of gets _____ _____ –

Bach: No, we reject that.

Melnik: So annoying and, you know, whether it’s development or testing or any other, you know, data science modeling, the UX design, it’s the discipline, it’s something that requires dedicated effort of studying, perfecting, thinking about the way how people do that work and it requires intellect. That’s the most important thing. You know, using some very powerful tools doesn’t give you the license to turn off your brain and I’m happy to come back on the show and talk about the different career letters and progressions because again, it’s going to take us a longer –

Shimel: That’s a whole other show.

Bach: There’s a lot to –

Shimel: _____ and vocal about that.

Bach: say about that. But I just want to note that this whole issue has been studied in great depth in another field, in the field of the sociology of science. For instance, in physics, theorists are in the higher caste and experimentalists are in the lower caste. So if you’re an engineer, you’re in the lower caste and they’ve studied this. How do these people cooperate? How do they assign prestige to each other? It’s a well-known phenomenon in many fields of human endeavor.

Melnik: And the same in math, right, the theoretical math versus applied math, the theoretical math seems to always think that they’re the gods and they’re the ones that are, you know, creating something that, you know, will take centuries for the world to truly appreciate and then you guys are in the applied math solving the problems of today.

Shimel: Exactly. Guys, we’re out of time, but I’m going to hold this – I’m going to hold you both to it. We’re going to come back on – not in the next show because I think we have something scheduled, but in one of the ones coming up, we’ll have you both back on, or maybe this’ll serve as part of our first roundtable in about a month from now when we’ll open it up to the audience as well. But for now, Grigori, James, thank you. Yes

Melnik: Thanks, Alan.

Shimel: James, thank you.

Gentlemen, it was a pleasure. This is Alan Shimel. You just watched the very first DevOps Unbound. We’ll be back in two weeks with a fresh panel, fresh topics, stay tuned. Thanks again to Tricentis for sponsoring and thank you for watching. Bye-bye.