Techstrong Gang – February 29, 2024

Hey, live on the gang today. We've got three big topics we're gonna cover. One is about what is the end goal of DevOps here, should it have an end goal?

Second, we're gonna talk about anti-patterns in DevSecOps. And then third, we're gonna have a deep philosophical discussion about what's best for society, working from home, working in the office, some combination. Who knows?

We've got that and more live today on the Textron game. Hi, good morning everyone. Alan Shimel here for Textron Group on the Textron Gang.

I'm joined by our usual gang members and a very special guest who's a long time Textron, uh, family friend member. But first, let me introduce our chief content officer sitting here to my left or right, depending on if this is mirrored or not. Mike Ard.

Mike, welcome. Thank you. Good to be here.

Yep. Joining Mike and I at, we're at Techstrong Headquarters joining us from there, abode on the road, and who says we don't allow remote working is our CTO and Chief, uh, research analyst at Techstrong Research. Mitchell Mitchell.

Ashley Mitchell. Welcome. Good morning.

Great to be here. Welcome everybody. Yep.

com. Amanda Reini. Hi, Amanda.

How are you? Good, Amanda. Just check you're not on mute.

com and been part of the family here for probably 9, 8, 9 years now. One and only Bob Ruman joining us very early in the morning out in la Hey, Bob, it's great to have you here. Uh, Great to be here.

Thanks. Good morning. Yes, good morning.

Um, alright, so I, I said in the preamble, we got three main, uh, blocks we want to hit on today. Mike, do you wanna kick it off? I do.

'cause it's gonna be a very philosophical show I start to finish. com talking about, well, what are the implications of AI for our fellow DevOps professionals? Because the goal has always been to quote unquote ruthlessly automate.

But if we automate to the point now where we, what are we, are we pushing ourselves out of existence here? Who will do what? Because as he points out, if the machines are writing all the code, well then what do we need all the folks for to manage this process?

'cause the whole thing will become highly automated. I know this is top of mind for you as of late, but lots of DevOps folks are wanting to know, where's my cheese going? So first of all, I would say that automation has not always been the chief goal of DevOps.

I think the chief goal of DevOps has been to break down silos and cultural among people, not process, not tools among people so that they work better together and in working better together. We can have higher quality and go faster if higher quality going faster entails automation, that's good too. But don't, don't underestimate the power of people and of culture and DevOps.

But I think we're mischaracterizing Don's article in, in all due respect, I think the point of Don's article is what is the end goal for DevOps, right? Because if, if the initial goal was to make people work together better break down silos, okay, we've achieved some modicum of success in that, right? Uh, we've added automation to the mix.

We've done a lot of that platform engineering check. SRE check, you know, DevOps seems to be this ever growing amoeba umbrella that encompasses many things. When is it finished?

What does success look like? What, when's, when's, when can we shut the oven off? And AI is just the latest check on, on this whole DevOps, uh, you know, uh, one's it done.

And, and it promises in many ways, as you said, Mike, to be the most, uh, impactful. But I, I think the point of Don's article is you have business people, right? The business team, dev BizOps, who's ruthlessly moving forward, let's do more faster, better, cheaper, right?

Automate, automate what have you. And then you have an IT team who says, you know, I'm just following orders here. Tell me what your priorities are and we'll make it happen.

I don't think the world's that clean cut. The other thing is, look, DevOps never had a definition. It never had a manifesto.

It never had, it was always amorphous by design. Why should that stop now? I'll leave it right there.

All Right, Mr. Ruman, since you are new to our show and a guest, do you wanna weigh in here because you are, after all one of the more deeper thinkers in the land of it, A Deeper thinker. There's another T-shirt.

Um, well, let's remember the days before DevOps. I was, I was actually working production at that time, and everybody get together and we'd have a major deployment and we'd all sit in a war room and they'd put in, you know, the potato chips and the soda and the ice cream and coffee and all that stuff. And there would be the zip files.

We'd be passing zip files between servers all over the place. That's what it was like. And then everything would go wrong.

And then people be there for the weekend and get really mad and do all that stuff. And one day somebody woke up and said, you know, there has to be a better way. There just has to be a better way because we can't afford it.

And my thinking is that the foundation of DevOps is, was, is and was, uh, financial efficiency. We just can't afford to keep doing this. And we, when we looked at it, we said, okay, well what's one of the big problems we have?

Well, we have dev developers in one pod making the zip files, and we have ops in the other part deploying the zip files, right? And that's just not working. And maybe if we got them together, that would work out.

That's the good news. The bad news. The bad news is, is that people can only identify that, which we know what to look for.

So what do I mean? If you've never, if you've never seen a giraffe, how can you go looking for a giraffe? Right?

And, and the reason I'm saying this is that what's happened in DevOps, it's almost become somewhat analogous to systems administration. When we start looking at what people are saying, well, you know, systems, you know, make the machines do system administration. The spirit of being able to, whereas Allen pointed out of being able to talk to one another and being able to do away with this all insanity of developers giving stuff to systems that admins and making sure it gets out the door goes away.

So what's the end game? There is no end game. I mean, that's what people want their software and they want their software as fast as possible.

So there you have it. I don't Know, Mitch, I'm gonna weigh in on that too. Yeah, no, I I, you, you got my punchline too, which is, I don't think it's a sensical question.

It's like, what's the end? What's the end game of waterfall or agile or weather? It's, there isn't an end go end game.

It's about adapting this approach to what's important in your business, right? If we are like in dire straits for getting software out, 'cause we really suck at it and it takes nine months to get a, a release out, which is kind of the days Bob was talking about. Which mean, back in those days too, by the way, you had your backout plan.

'cause about half the time you had to back it all out and go re re upgrade again. But it's about, you know, what's important to the business, right? Do we want to implement ai?

Well, that doesn't mean no DevOps or DevOps. It means that's just a way of doing software. So to me, to me it's not, I, I understand there are business goals and measurements for success.

Those are all great. That's not an end goal. I will argue something.

Oh, go ahead, sorry. Oh, well I just wanna jump in on what Bob said about the deep thinkers and um, and also what you just said, Mitch. So, what spoke to me most in that article was if there was some sort of end goal, and the end goal was use AI to automate everything and remove it roles, then the question is going to be where are the deep thinkers, the philosophers, that question situations that could come up in the future, or problems that don't exist yet.

If there's nobody writing code and there's nobody able to do those things, then AI's gonna come to a point where it can't solve issues in the future. And that would be concerning. So that was interesting and made me think that we need to keep the human element, the philosophers and the deep thinking about the future.

I would argue there is indeed a goal, and I'm gonna disagree with you. And the goal is to make this stuff as transparent as possible. I think, um, we had John Willis on the show.

He's a big fan of, uh, touring, I think it is. Who said Deming? Deming.

Deming, sorry. Deming who I think said something to the degree that any process that you can see is broken. It's pretty clear to me that we see DevOps all the time and there's tons of bottlenecks.

So therefore it is broken. AI may move it along to, from where it is today. But I think the ultimate goal is to make it so transparent is that you don't see it, you don't experience doesn't mean it goes away, but today we're too much, um, noise in the system that results in rollbacks to Mitch's point or results in vulnerabilities that aren't addressed.

I think we got a long way to go here and maybe AI's a step in the direction. I gotta call BS on you, man. All right.

Because I'm gonna tell you. So something, if you don't, I will. Exactly.

And Mitch is ready to jump through the screen because guys, I gotta tell you, we have less rollbacks today than we ever did. That's damn short. Right before DevOps, you know, upgrading to a new version was hit or miss at best.

You know, that 12 inch stick in my eye is so much worse than the six inch stick in my eyes, so it doesn't really matter. Okay? And then, but the, but secondly, secondly, not, not just the rollbacks, but vulnerabilities.

S**t. Excuse my language. Oh God, at least we scanned for vulnerabilities before we deploy code now.

And that's actually part of the process. We never did That. I wish we did scan, but it's pretty clear from every guy article that we write on Security Boulevard that we are not scanning No, no, we are scanning.

There is an article today, in fact from file did their research showed that hardly anybody scans any of the packages they download from the JavaScript files. And so it's just kind of, It's a mess. No.

So you're talking about SCA, right? Software code analysis is those things. So we scan more those than we ever did before.

Now do we need, can we be better? Yes, but let's, let's be clear, software coming outta the shoot today is many, many times more secure than when Mitchell and I and Bob were were what, you know, they were referencing sitting around with the potato chips and ice cream unzipping zip files. Oh.

And we had to get it done. And I, I got my kids' birthday this weekend. I can't be here all weekend.

Screw the scanning. I'll do it later. We've automated scanning.

Could scanning be better? Could scanning find more vulnerabilities? Yeah.

Yes. And it is, it's getting better. But make no mistake, you know, it's very easy to put the, the rose car colored glasses on a wax nostalgic about the old days.

The old days weren't the good old days. Hardly At all. I don't think anybody's saying that.

I'm arguing That we've made tremendous progress. You were describing the Stanley Steamer age of software development and the rest of us are going, where's my flying car? So, exactly.

I did read that article and I was a little surprised of, of the, the vast percentage of incidents they did find. I think it was like 47% of malicious code in the software, which seems kind of high to me. So Mitch, what do you say?

Well, um, sorry, not to gloss over what you said, Amanda. 'cause I'm thinking about that. I go back and re reread that part of the article.

Um, I think so I'm just gonna pick on you a little bit. Not as much as, as Alan did, Mike, the flaw in, in what you said was DevOps is not a process, right? It's a, it's a method, it's a, uh, an approach to developing software.

So it can't be invisible. 'cause you're continuously improving all different aspects of it. And that's why rise of DevSecOps and platform manage all these different things come about.

Or you can localize it just about CICD, which I think we're gonna talk about in a bit. So that, that's my argument about it shouldn't be invisible. It should have low friction and it should facilitate getting software out the, the right software out the door at the right time yet.

But, but yet, I'm sorry. Yeah, Bob. Oh.

And, and yet we have the corporate paradox of the title called the DevOps engineer. If DevOps is a way of life, then what does a DevOps engineer do? Engineer my life, right?

But there are people out there lined up around the corner trying to hire DevOps engineers, right? So that's sort of, that's just sort of strange to me, which is, again, going back to my argument that this notion of DevOps can only be interpreted in the language you have, which is, if I'm a system admin, guess what DevOps is? Systems administration.

Right? Or if I'm not so much a system admin, if I'm a corporation or an I or a CFO or an A CFO, more likely I can only imagine my organization to have, um, system administrators, people that run, you know, turn the dials, people that, you know, uh, um, tighten the bolts. And for that, I need an engineer.

I need a DevOps engineer, which, you know, meet, meet the old CIS admin and new, his new CIS admins did DevOps Engineer, he makes that's my, well, makes more. But Bob, he makes more money as a DevOps engineer. Yeah, that's true.

That's true. Okay. Or he is actually, he's gonna make a lot more money being a platform engineer.

Engineer. Exactly. There you go.

But, but let's talk about bottlenecks for a second, right? You know, again, I'll go back to, to, uh, Phoenix Project, which is based on the goal, right? The very nature of, of business in the goal it was manufacturing in, in, uh, Phoenix project, it's software manufacturing is, there's always bottlenecks.

You're never gonna be done with bottlenecks. You're never gonna reach nirvana by definition. It's almost unknowable and reachable.

You can know, you know, it's like knowing God. You can't really know. It's a, it's something on faith and you don't know the essence of, of, of the deity.

Um, but the very nature of this process is as soon as you solve one bottleneck, it now gives you vision into the next bottleneck and so on and so on. And you, and, and to a certain extent, that's the way of DevOps the same way. It was the way in the goal is trying to get to those bottlenecks and solve them as quickly as possible so we can get to the next one.

And that's the whole right to Don's full circle to Don's article. If the goal is to remove bottlenecks, you're never gonna reach your goal. And maybe DevOps was set up that way to begin with, never to have an end goal.

Have we, have we exhausted this? We have not. Okay.

Mike's ready to go. I'm gonna, I'm gonna come back on it and say DevOps is a means to an end. It is not the end in itself.

And therefore, what is the end? And the end is to make the business more efficient, more effective. I would argue the DevOps tail is wagging the business dog.

Because now the business is having a hard time keeping up with the pace of change from DevOps. There's still work to be done on the DevOps side, but the business side of the house is sitting there going, I'm not sure we can absorb the frequency of updates and changes. We see it in the digital transformation conversation all the time.

But DevOps is itself, is not the goal. It is something else. It empowers mm-Hmm.

I don't know. I'm talked out on it. Mitch, Amanda, Bob, anything else?

I'll throw one more thing in is, and I think what's changed with DevOps is that the frequency of change is much greater, but the degree of change is much smaller. You know, the days of Bob and I sitting in the conference room, you know, why didn't the, the implementation, what, what happened with the installer? The database conversion script, you know, those, those days are over.

So we all live in the, in this world where we're in our software's in constant change, how often does Zoom and Chrome and everything else we use update itself every day? Now getting a an enterprise system to working in that kind of fashion is no small feat. But I think the change can be smaller, Mike, than what the business is used to saying, I, I just changed our process to match the new version of software.

Don't change it again. That, that's kind of the old days. At least to me it is.

Fair enough. All right, you know what, let's take a quick break. And by the way, excellent article to our, by our friend Don McVety.

But let's take a quick break. We'll be back here in a second with more text on gang. All right folks, welcome back.

We are now gonna talk about our second favorite most contentious philosophical topic. DevSecOps, our friends at Techstrong Research have a new report out about any patterns as it applies to CICD and security. And I'm gonna let Mitch explain what's in there.

But it seems like to me, just to get the argument started, you know, we're saying you should take your vitamins, but I don't know, what do you, what's in there, Mitch? Yeah. Every day.

But, but you know, we don't always do that, right? Well, so, so what this was about is actually is a collaboration with Red Hat, looking at, uh, supply chain security, a software supply chain security, and thinking about the DevOps pipeline in particular around the CICD process. But you can think about it more broadly than that.

And an anti, the definition of an anti pattern, at least for the purposes of this report, is a pattern or, or practice that kind of gives you a false sense of security. Like doing these things. I'm good, I don't have to do more.

That's, that's, you know, that's fine. I'm secure. So scanning images that I put into my software supply chain, uh, getting them from a reliable source, uh, scanning for vulnerabilities, those are all good things.

Nothing wrong with that. But is that enough? If it was enough, we wouldn't have supply chain attacks.

So we, we talk to people about what are they doing to secure in the inside of the, the workflow pipeline, the DevOps tool chain, and how software and, and workflows through that. And sort of the, one of the interesting conclusions was one approach that's being used is using kind of a cloud native, some aspects of it where you containerize and compartmentalize different parts of the, the CICD process of the supply chain and secure it at a more granular level. And people were using kind of that approach, barring some ideas from Cloud native and things we've had before, cloud native.

But that, that was really interesting to me and how many people were either considering or doing that. The other is, you know, there were substantial number of people that were reported they'd had, uh, some kind of a breach or some security incident in their supply chain, uh, in their own software development process. So, pretty fascinating work.

I thought it was great to work on it. Bob, what's your take on this? And I'm gonna ask you this question in this context.

Um, we hear the phrase sh shift left all the time. So who should be in charge of this security? 'cause some people would say, pardon my French, that Shiff left equals s**t left.

And people are complaining about that. The developers are saying, I can't handle a cognitive load. I can barely do what I'm currently doing.

So where does this DevSecOps security function belong in your mind? It, it's a good question. 'cause this is, you know, one aspect of it, this is about securing how the pipeline of where we create software versus the security, the software we're creating in that, that flows through that pipeline, if that makes sense.

And, and, and it's pretty clear that, you know, you, Bob was talking about, you know, the s admin, you know, new boss, the same as the old boss, right? The DevOps engineers doing this work. Those are the people who are really probably gonna have to do most of this heavy lifting.

'cause the security isn't gonna go in and configure Jenkins and configure, put it into containers and do all those things, right? Maybe some platform engineering might help if, if they need that. But it's really a system administration function for the development tool chain.

So I think in that aspect, it lives more in the people who support the underlying tools and how they integrate and how they're secured in a software development process. Bob, appreciate your perspective on this. Yeah.

Question and feel for you to disagree if you don't think this Is a thing or not. No. I have a question.

Uh, for you, Mitch, when in your research were, were the companies looking at the artifacts or were they looking at the, uh, the, the, the artifact deployment process? Um, 'cause I, and I'm, I'm asking you that was it for more, okay. We're just, we're just gonna take the code, we're gonna stick, scan the artifact, or we're gonna send it out.

Or were they, were they actually looking at the process of which inspection happened? That's my question to you. Yeah, it is a great question.

It kind of goes at the heart of what the research about. Yeah. Looking at the artifact, most people are doing that, the scanning and making sure what you're producing is secure.

What you're consuming is secure. But there, what we're starting to do more work on is securing the process of how that auto artifact flows and then gets out the door to the, to your ladder example. So that's, and Then That was the real kind of aha In it for me, right?

And then it goes to architecture. So I remember when, when I was at one company, one of the big battles was whether to have your own private repository. And this was back, not, not, it was back in the middle days of, of Docker.

So are we gonna go out to Docker? Are we gonna trust that, you know, the, uh, the images out there are secure? Or are we gonna say, no, we're ne we're never gonna do that.

We're gonna create our own repository. We're going to use images that are only ours, even if it's a well-known, uh, image, we're still gonna bring down those docker files and that source and do it ourselves. And that was a huge fight.

That was a huge fight. Mm-Hmm. And that was a huge fight.

And that was a fight that actually the company I was at at the time got lost. They went right to, they, they relied upon Docker. So now the question, is it also in saying the CIS admins also is, well, what is the, what are the role of these, you know, enterprise level repositories?

And I, I'm seeing that. I mean, honestly, I get caught in, um, when, when I, when I run an NPM install, uh, I get caught a lot. I get caught a lot.

If you do, you got a lot of high vulnerabilities in there. So it's showing up in my work, but the honest, if I'm doing just a demo, I check it in. Mm-Hmm.

And so now who's insured there? You know, Bob did a baddy, right? And so what, in, what in the development pro in the deployment process is one, where's the security check happening?

And I defer that to you, Mitch. And the other one is where, what is the se security architecture again? Local repos, global repos.

And you got me, I'm, I'm interested to learn. Yeah. Uh, it's, I think that debate is still going on very much.

Um, Rob, uh, Bob, sorry. Uh, but I think the thing that's shifted is we're not gonna just rely on a, uh, you know, some external repository where it's docker or it's anything else. Um, where are we getting that stuff from?

And then let's bring that into our own environment and make sure it is what we think it is, and that we consistently use that from our repository and flow it that way. Now, is everybody doing that? I don't think it is.

So, and I promise I won't call you Rob again, So That's cool. Why not? This is, yeah.

His name is Robert, but, um, It is Robert. Yeah. Before a judge.

Yes. Yes. But to me, not trouble.

So we don't use that name. But to me, here's, here's an issue though. It, it's more of a, who's watching the watcher Issue?

Yes. Yeah, I Agree. Right?

So we, we have, we've, we've put in these processors that theoretically not processors, processes that theoretically you're checking the software that we're getting from repos, whether they be public, private, local, global, whatever. However, we're relying on the software that's checking those artifacts or repo items to in fact, be themselves not corrupted. Right?

And who's watching that? Who's checking that? Who's checking the tools we're using on the factory floor to, to assemble the software, right?

And so it's not the classic dev sec ops conundrum of, let's throw another straw on the developer's back. It's more of a, who's watching the watchers? Can, can these tools be self run, self checks?

Do you trust them to run self checks? You know, um, should there be a, an integrity check of the tools as part of your SBO or something like that to make sure you know, nothing got introduced after you downloaded it from whatever repo you are using. There's, you know, again, as soon as you solve one bottleneck, we find the next bottleneck.

As soon as we solve the problem of scanning software coming from repos, we, we worry about is the scan, are the scanners corrupted? And, and I'm sure once we fixed, we'll solve that. There'll be another bottleneck issue we need to hit on.

And I, but you know what? That's, that's why this tiger has stripes. Maybe Mitch, do you think maybe it's a hollow debate, right?

We see it in the industry all the time, but the more I think about it, I'm kind of like, trust nobody, the developer, don't trust them. But there's gonna be stuff thrown into the build. Don't trust those people.

'cause they can make mistakes as well. And then by the time the whole thing gets deployed in production, somebody's gonna do an update anyway. So you gotta check it on the far right side of the equation.

So maybe we should just be, you know, I, we throw around the phrase zero trust, but I'm more of the presume everybody's guilty till otherwise proven innocent That, and that is zero trust. Mm-Hmm. And that is zero trust.

Well, you hang around with security people long enough and you're, you know, software folks will become that way as well. I, I think it's, I I think it's more taking out the, well, I personally trust them, and I think that's a good source. And I'll use that and I'll download my code from there, which you can do on your own or smaller development team.

But it's more formalizing where are we getting our code? How do we know we're getting it in a way that it's secure? And how are we know that we consistently use that as opposed to something that might have been ingested or added to it.

It's almost like, as you were talking down, I was thinking about, it's like the movie inception. How many le how many layers deep do you have to go to plant that seed, right? That's gonna change an outcome.

Um, and that's kind of what what we're describing is do I have to go look in every piece of open source software that I deploy in my code? Well, maybe my scanner's doing that, but it's probably not doing all that either. So at some point, you know, there's a diminishing returns, right?

We will never stop scanning. Yep. So the, the, the other point about it though is, you know, philosophically zero trust sounds great, right?

What could be wrong with that? But then it runs headlong or head first right into the wall of I gotta do more, faster and zero. You know, the old saying about your civil rights end at the tip of my nose, zero trust is fine until it runs into the tip of my, I want to go faster debate.

And that's what happens is zero trust can wind up slowing things down. And and when they do, people scream. When it does people scream.

I'll throw this out to one of you three remote folks, but, um, there was a book a long time ago, Ralph Nader wrote it, it said, unsafe at any speed describing cars. Are we unsafe at any speed with software development these days? Well, I think there's always gonna be a safety issue, but it just requires constant vigilance and good communication.

And maybe as the article said, some frown work, some groundwork, uh, that, uh, needs to be put into place. And, um, just having a good plan of action, um, for defense. All right.

I think we can end it there. But to Amanda's point, I think the saying goes something like, um, freedom requires eternal vigilance. Is that where we are?

I've heard that before. It does. You know, I'll also put in that democracy is the worst form or the best of the worst, right?

And, and that's kinda what we've got. All right. We're gonna take a break on Text Trunk Gang.

We'll be back here in a second. All right. We are back with our third philosophical argument of the day.

And we're talking about this whole push to get everybody back into the office. There's, uh, an interview that we did with, uh, Tite Patal, who's over at Cisco. He is one of the senior vice presidents.

And he has some things to say about, well, why you may not wanna have people come back to the office. Let's run that clip for a second. The future of work, in my opinion, I very strongly believe in this is gonna be hybrid, where people are gonna work in mixed mode.

There'll be times that they go into the office that there'll be times they wanna work from home. There'll be times somewhere in the middle. I actually think it would be like very regressive for society if we required everyone to be back in the office five days a week.

Because what that does is makes geography such a disproportionate, um, you know, prerequisite for economic participation and economic success. So I actually don't think it's a healthy thing to go back to pre covid days. And everyone worked from the office five days a week.

I think the next generation of leaders need to figure out a way that they can build strong bonds and relationships and serendipity while being, uh, while never having met someone in person. All right? So he is saying that having everybody move to New York or San Francisco, or Chicago, wherever it may be, is bad for society.

It's bad for the economy. It, uh, reduces the ability to have jobs that they can have well paying for and live in nice little towns somewhere that would in turn drive their local economy. I know we have talked about the merits of working in the office versus remote.

What's your take? So, I have an opinion or two on this. So keep in mind myself, I and Mitchell knows this.

When we co-founded Still Secure, I worked remotely for the most part for 10 years, 13 years. Not true. When we first started the company, I actually lived local in the Boulder area for three or four days a week and then commuted back and forth.

Um, I've been through Covid as we all have, and I'm talking as a CEO now as well. There are layers and layers to this discussion. The first discussion I'm gonna answer strictly as a CEO, I don't care what you tell me.

Doing this on Zoom is not the same as having Mitchell, Amanda and Bob sitting around this table with us. There would be more interaction, there would be more productivity. There would be a warmer feeling of togetherness than than doing it like this.

If I had my druthers, I'd fly them all to Florida and do it here, right? And that is equally as true with people working in office. Yes, there are certain disciplines, certain, uh, job functions that it's not maybe quite as important to, but overall from a societal impact, it, it, it works better when people are together, no doubt about it in the same place.

And, and back to your society point, You got this finger weighing at me. I'm sorry, I'm sorry. Um, to your society point, you know, I'll take San Francisco as the perfect example, right?

San Francisco in many ways a ghost town today. 'cause it's not just the people aren't in the office as much, but you need a critical mass of people in the office so that the breakfast restaurant has enough customers to serve breakfast to so that the lunch places and the bars after work and restaurants have places so that the dry cleaner can drop people, drop their stuff off and do their thing so that the print shop down the block and think about all of, and if I want to go retail shopping during my lunch, not on Amazon, I want to feel a shirt. Right?

You need, I mean, this, this goes to fundamentally, you know, society. You need critical mass of people. It would be nice if Mitchell was out on some big cloud ranch in Montana, and Bob was on some seaside villa and Baja California, and Amanda's out on St.

Pedro Island. And, and you are up in Galloway, Ireland, and I'm sitting here, right? And you all would be really happy, but we wouldn't really, it's hard to do a business like that.

Are the tools better? Yeah, but I I I think they're a, a pale in comparison of working together. All right.

Any of your remote folks have something to say about this? Well, I will say, um, while I see so much value of coming together in person, and I hear everything you're saying and do agree to some level, I think what outweighs all of that is comfort of working from home. Um, in, in the environment that you enjoy.

You can be in your pajamas if you want to, you can work. That's exactly my point. If you're in your pajamas, go get a different job.

I don't want people in their pajamas. I want people dressed for work. Because how you dress has a lot to do with how you look at what you're doing.

Well, if you're in your pajamas, you're sitting around having fudge brownies. I beg to disagree. I think the research and the studies are showing that people, when they're working at their comfort level, maybe it's morning, maybe they're morning people, maybe they're night people, or maybe they're midday people.

I need work done when work needs to get done. Not when you feel comfortable. I'm, I, my world works on nine to five.

The fact that you got something done at 10 o'clock, God bless you, but I needed it at five o'clock. And how, wait, Alan, how do you really feel about this? I'm telling you, I have strong feelings on this subject.

I don't need people dressed in their pajamas. I don't dress in my pajamas. Right?

So, Well, let me, let me tell them. Okay. So yes, at one, I admit at one time I'm Bob and I, I'm a recovery executive.

Um, and, uh, yeah, one time in, in my, my my, my long and stellar career, I, I was CTO of a of a, of a emerging trading company on Wall Street. And, um, I worked in New York during the week and I went home into the Midwest on the weekends. And I found, and my flight time was, uh, my flight day was Monday.

And I found, I was, found myself getting paranoid. 'cause I couldn't watch what people were doing. I really couldn't watch what people were doing then.

What are they doing? They're probably smoking cigarettes and having a party when I'm not there. So I would start, then I changed my schedule to go every other weekend so I could watch them on Monday.

Right? And so that was more my, my paranoia. I, I, and then, so if they all went remote, I wouldn't know what they're doing anyway.

'cause the paranoia is mine. So go, go. Going back to your, your point, Alan, as much as we'd like to have people in front of us, the, the trend, the heuristic trend I'm seeing is those days are gone.

Uh, I buy a lot more from Amazon today than I do from Ralph's down the street. As a matter of fact, the only deal there are, there are three retailers I go to now. I go to Ralph's down the street to get, get stuff that's not a Trader Joe's down the street.

And then there's a guy, uh, that I go to get to get a haircut. That's it. Everything else is pretty much done online.

So the notion we're, we're all online now, but we're not all online because the, the stuff that this remote stuff applies to is knowledge workers. The guy, you know, the, the, the, the 30 the 30 construction workers building this building down the street from me, they're not online. And it's interesting, they are remote because in a sense their, their managing office is about 10 miles away.

So the point I'm trying to make here is, as much as we'd like to, you know, have people in front of us and enjoy that productivity and that intimacy, yeah, we're all shopping on Amazon now. And that, that's our future. So Let me, let me run with that a second.

I shop on Amazon too. Whole Foods, right? And I have Instacart and all that.

Amanda, do you do shopping in person or online? It's a shopping. It's a good mix of both.

For me, I, I'm more of a, I would call it hybrid, Mike. Yeah, I think everybody's mostly a hybrid. So I will tell you yes, for packaged goods that you would get on Amazon, but I still, for, when it comes to supermarket shopping, I like to pick out the specific fruit that I want.

This is a good apple. This isn't a good apple. When you order apples from Amazon online, you, you don't get the good apples.

They take whatever the first three apples are and throw 'em in there, or the kinds of fish. And I don't necessarily know what they got fresh local in the market that day. So to me, there is no comparison of supermarket shopping in person versus doing that online.

Um, and it's the same thing with buying clothes. Yeah, I could buy my clothes online now that I've lost some weight and I, I could fit into better clothes. But until you touch it, you don't know.

Mitch, is this a, a technology challenge that we're trying to solve here, ultimately? Because theoretically, at least I could have an algorithm that might tell me how fresh that Apple is before it was thrown into a package and shipped to me. Are we just on a journey here and we kind of rushed it because of Covid, but ultimately, you know, there are gonna be technology innovations, there's gonna be better video, more ai.

Are we on just on a path? Well, I don't know. To, to me, we're on an evolution of doing more and more online.

And the shop, the grocery shopping example is a good, a good one of it ain't there yet. The bane of grocery shopping is substitutions. I don't want that brand of peanut butter.

That's not what I asked for. And I told you not to substitute. You know, there, there are still issues to work out with it.

You know, I, that fish doesn't look fresh like what I like to buy. So there, there are things that aren't there yet, you know, and they're evolving. Maybe they won't get there in, in the world that in the, it shouldn't Bob's opinion, the world of Bob and I live in of software creation, you kind of go with where the talent is.

And I can't get everybody into Denver, Colorado, or Boca or LA or what, or just hire people that are local because the talent that might be available, the person that's really one on the team is in Austin. You know? Yeah.

Come join the team. Or, or in Bangkok, right? Or Bangkok.

Yeah. Right. Exactly.

Exactly. So then we get in, you know, the whole wage compression stuff, which is, you know, and another, you know, another story. What will be, what will become interesting if is if we watch the e the elu, there's two parts here.

The, the evolution of the online experience and this remote work. I'm still, of the opinion that remote work I is, is that is affected, or I'm losing my words here, but it's affected to knowledge workers. And that's only a section of the economy or everybody else.

They're, they're still real time. They're still real time. But if we look at the, the evolution of the online experience, remember, you know, Amazon started with books and now if I get a, um, if I get a thumb drive that doesn't work, which is a non-perishable commodity, if I get a thumb drive that doesn't work, I just take it down the whole foods and I'm credited within, you know, Seconds, Uh, mint seconds.

And so my whole shopping experience is no worse than going down the best buy, bringing a thumb drive home down the street, putting it in my computer doesn't work. And I go back to Best Buy. The, the reason is, is that the evolution of, of the business process is such that they, it's almost immediate.

So going back, so what's the next one, Alan? You're talking about high perishables. So what happens if Amazon says, okay, first of all, we're gonna guarantee the quality.

And they have, you know, their AI looking saying, oh no, Alan and Bob and Mitch returned all these apples. 'cause they weren't any good. We've gotta to implo improve our QA around our fresh produce.

And eventually all the apples start showing up. Cool. Mm-Hmm.

That's where it'll be going. All right. So let me take what they're saying.

And with all due respect, you're Doing a lot of this today. Basically, Basically, basically Bob and Mitch said, Hey, boomer to you. Mm-Hmm.

And, you know, do you need to learn how to manage in a new world and a new reality? And we can long for the days when we all hung out at a table. And there is much to be, uh, benefit there, but it's never gonna happen.

Yeah. So when, and, and when it does happen, gimme a call. But until then, I'm telling you that people are not as productive working remotely because, and, and Amanda, I'm not picking on you.

I love you, but Amanda hit it right on the head. If she wants to dress in pajamas today, she'll dress in pajamas. If she's having a nighttime work day, she'll work at night.

I, I can't run a business like that. I really, I can't. And I think it does come down to if it's project driven work with deadlines, or if it's, you know, truly hourly, you know, you're needed during certain hours.

So it depends on the work it itself. And, um, like Bob said, it's only a certain type of knowledge work that can be done online That works like this. But I'll give you another example.

To Bob's point about Bangkok, look what, where's the biggest outsource for, for software development? India, Bangalore, or other cities in India, Pune, and so forth. There's a good chunk of Bangalore that works on North American time.

These people get up and they work on our time because that's where their work is. I think that's kind of the way, and, and I'm, and I'm not, you guys can make me feel bad all you want. I'm not alone in this.

I've got some pretty smart people who are saying the same thing. Well, we can just say to people, don't put your PJs on from nine to five regardless of where you are, because you are working with people. To Bob's point, I'm not paranoid where I don't, I gotta see people to know they're working.

I know Amanda works, I see her output. I see how many articles we publish. The the point is, how much more productive could she be if she was sitting in the same office as you?

Right. Right. Because she uses Slack.

Part of this remote working thing is you gotta use the tools, use the nice Job, Alan, that, that Our slack anti-pattern That said, we cannot find people as smart as Mitch and Amanda here in Florida. So We can't, so we, and maybe that's the reason why we need shouldn't be in Florida. Yes.

That's what I was gonna, it brings us us to the fact that we're casting a wide Net. Uh, we don't need measles vaccines All the full of talent. Yes, you do.

And, and so look, I I think there's a pendulum that swings here, right? Mm-Hmm. Um, even prior to Covid, when we were seeing the boom times in tech, you hired an a software coder.

If he was in Timbuktu, you would hire him because you need as many software coders as you can get. Now, as we're seeing these layoffs and we're seeing the job market tighten up, now employers are getting a little more picky saying, I don't want that guy in Tim book too. Definitely.

I want the guy down, down the block. Definitely. You know, Alan, one thing I would say, I, I do agree.

When you're face-to-face, I mean, when we went or like have an important meeting or a, a whatever working session, we all get together wherever it is. Boca in our case, um, there's a lot to say to that. I think one of the dynamics we don't talk about is a lot of what you're saying is ex very true for smaller, medium sized teams, right?

When we're working on projects, we're working on something, we're solving a problem getting together. When you get into larger organizations, you still tend to hang out in your area. My floor of the building, I don't go to the other floors that often, unless I got a meeting up there.

And it's not that frequent. I definitely don't go to the other building, uh, unless I really have to go. So in, in larger corporations, the, the idea of bumping into together in the serendipitous, you know, innovation stuff happens, but not, not to the same level that it does at smaller teams.

Yeah. So I think that's where, where the everybody's gotta be in one building is b******t, because those people are not gonna run into each other. They're gonna see each other maybe when they walk into the building, and they're gonna work with the people that they work with.

So, but when you need people to work together on something, the best way is to get 'em face to face. I agree with that. Fair enough.

It's kind of like when you're texting somebody over and over again and you're con continuously going back and forth, texting, texting, texting, texting, and finally you just pick up the phone for a phone call and you get everything taken care of right away. So I think most of the time, working remotely is great and, um, everything's spinning along, but then when you just really need a lot of things to come together, being able to meet in person at least once a year or twice a year is so effective. So with all due respect to my colleague who calls me a boomer, when he's a boomer as well, this is a big issue I have with my kids.

Mm-Hmm. My kids refuse to pick up a phone and actually talk. Everything is text.

Mm-Hmm. And, and again, being remote and texting, you lose a certain intimacy, you lose context, you lose. It's not the same as even talking on a phone, let alone being in person.

And you know, and, you know, are we destined to live in a world of Wally where we're all gonna be fat blobs sitting on a chair at home, ordering our Amazon, slacking our coworkers, and having AI write our stuff for us? And, and you know what, what's the meaning of life? Yes.

The answer's yes. That's, that is the end state. That is the future.

Ha Mitch, uh, that Doesn't sound too appealing at the end of the Day. No, no, that does not. At the end of the day, the human element and inner, you know, the relationships are so important.

Safe San Francisco. Well, You know, yeah. And, and then, you know, back in, you know, back and forth cars, you know, hay was important because the horses needed them.

Um, and so, you know, the, the, the, the point that I'm making about that is that the experience will change. And the notion of what it means to be engaged is going to change. The more, the thing I, the thing I worry about is that we just become so removed from this thing called reality.

So for example, we, you know, in the old days when you used to get fired, at least you got called into a room. You got called into a room, and there were three other people in the room, and you had to sign some papers. And then you're given your severance check.

You know? Now, now you get an email. Yeah, That's true too.

And what does that mean? Well, what's that? What, what?

And for us, you know, we are, we are, many of us here are boomers. So it's like, it's like an amusement to us. Okay.

Okay. That's cool. Isn't that cute?

He just got fired by email. But what happens when that majority of the workforce that does work online, that's their experience of being hired, working and being fired. What does that do to one's perception of reality?

I don't know. But we saw that poor woman who was fired and she recorded it on video. And I think they, in hindsight, they'd rather have sent an email.

Well, the email is a aesthetically clean, um, maybe impersonal, maybe depending on the content. Impersonable, because I mean, to, this is a great point. Look, getting fired is a traumatic experience for anyone, even if you want to get fired, right?

And, you know, the fact that we do it sort of surgically veer an email or, or in the case of, uh, X Twitter, whatever they call it today, right? They didn't even send the email first. First they cut you off from all of your e from your email and your, you know, resources and stuff.

And then you had to kind of figure out, this means I'm fired. Right? That, that's not, that's not human.

That's not the kind of company as a founder of a company that that's not the kind of company I wanna run. And, and, and I, unfortunately, we like everyone else in tech, we've had our share of layoffs. And you know what, it's not a happy thing to do, but it's something as the CEOI feel very responsible that I have to do.

It. It, it's not my favorite thing for sure, but I do it because the people who were having to lay off or let go deserve it. Mm-Hmm.

And that's why, um, Mike, if you can see it in your video game, Alan, right? They don't deserve to be laid off. They deserve your attention.

They Different, they exactly. They deserve. They deserve, right?

They do. And I feel like it's my responsibility to do that responsibility because they deserve better. And, um, anyway, I think there's two things that we should address when it comes to this topic, which is number one, while the majority love working remotely, and that is the way, and that is the future, we do need to think about the, the mental health of those who are struggling with working remotely.

Um, and the isolation. So I think we should talk about that, but also about the technology that does exist and how we harness that technology to make the remote work environment feel as human and close, um, as possible. Like removing the distance and making it feel as personal as possible.

And there's a lot of technology out there to do those things. Absolutely. But those are for a future version of tech, uh, future episode of te uh, tech Drunk gang.

We've gone over our time today. Hey, we hope you enjoyed it, Bob Ruman. It's so, I appreciate you getting up so damn early in the morning out there.

Um, see if you didn't work remotely, you'd be right here with us. But, um, thank you very much. We'll have you back on soon.

Keep doing what you're doing. Roll Bob cartoons, occasional essays. Bob, just give him a Google if you're interested in seeing some of the great stuff he's doing.

Mitchell, Amanda, we'll speak to you soon. Mike is always great show. Thank you.

All right. This is Alan Shimel, Mike Ard, Amanda Rini, Mitchell Ashley and Bob Ruman. For Textron Gang, we're outta here.

com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, tools, DevOps, culture, DevSecOps, business impact, continuous testing, continuous delivery, and more. com has the largest collection of original DevOps content, featuring breaking news, blog posts, podcasts, and more.

com to learn more. com where the world meets DevOps.