Techstrong Gang – May 6, 2024

Hello everybody and welcome to the Techron Gang. Today we're gonna be talking about everything from DevOps and AI to, well, what's going on with internal developer portals and developer productivity. And finally, we're gonna have a little chat about golden templates and platform engineering.

'cause we can't figure out if this is good news or just a new form of golden handcuffs. We'll be back in a minute. All right.

Welcome back. Our first topic is generative AI and DevOps and software engineering. There were no less than four different developments this past week on this topic, including Atlassian was shown how they've created a Robo AI agent to help manage software engineering workflows.

Then we had, uh, the folks at GitHub who had previewed something last year, say that they have now moved that to a technology preview, which is similar. And we have also, AWS announced a general availability of a tool called Amazon Queue for Developers, which is a variation of a tool that they announced at their conference last fall. And finally, little Tiger Graph also announced a tool that also customizes access to LLMs in a way that doesn't provide, um, any need to go chat up a data engineer.

And what all these things seem to have in common is that they are using a knowledge graph underneath to kind of connect all the data points together. And then I expose that to the LLM and then the LLM will be able to gimme output that's real relevant to the data that I have. Mitch, I know you were at the Atlassian conference last week.

Why don't we get started with you, but what's your impressions of what's going on here? Because from my perspective, it was kind of like I really wasn't thinking about knowledge graphs too hard up until about last week. Well, it's interesting.

Yeah. I was at Ground zero at, uh, Atlassian team 24 for a few days this week, and had a chance to talk about 20 different people doing interviews there. Essentially, you know, if you think about Atlassian, usually people have known them for Jira or Confluence, one of those two tools, at least traditionally.

That's kind of how we thought of at Atlassian. And they've greatly expanded their portfolio and moving up into the enterprise and up into workflow kind of applications, not just IT itself, but what's unique, and I saw this last year when they announced Compass, which is like their developer kind of management metrics board, which is part of where their API tool now reports into is under, you think about all the content of workflows and, and IT activities and tickets going into operations for whether it's HR or IT or any other organizations. What they, what they're, they call their knowledge graph a teamwork graph.

And so their point is, they not only know how data connects together, they know what people are doing, what work they're doing. And so if you're saying, Hey, I heard about their example that, uh, at their CEO and now I showed it the, at the announcement, if I wanna know, I heard about this thing called Project Blueberry, right? And if I'm one of the people that can know about blueberry, I can say, what is it?

Who's working on it? What are the activities that are going on? Um, because they've stacked on top of or incorporated with Jira, things like metrics and KPIs and goal setting and things like that they've set on, um, tracking for projects and doing more, more robust project management as well as ITSM and things like that.

So that, that's one thing I think that's unique about them that maybe then just a general knowledge graph. I, I think the other thing about them is I had a chance to talk to one of their researchers who, uh, was heading the development of part of this product is they've created a, an AI platform that supports these things across the different ai, uh, VO and other elements that are showing up in the, in their user interface. And so, uh, they're very much a platform approach to it as opposed to, here's the tool that'll take a knowledge graph and try to connect all this stuff and make sense of it.

And, uh, I think that gives some a particular advantage over maybe some other folks. All right. Tracy, you were at a hackathon we hosted a few months back, and as I recall, everybody was trying to do handstands to figure out how to expose data to this LLM here, and that went over there and mm-Hmm.

Now I looked around and all this stuff seems to be coming increasingly automated. So what's your sense of what's going on here? Oh, gosh.

There's a lot to talk about here. I think the Mitch hit on something that's very important. This is actually a point that I keep coming back to for the last number of months as I've been researching, as I've been working with different clients and different organizations, the importance of platform.

Um, what we're not trying to do is reinvent the platform. Um, that happened 15 years ago where you were locked in. If you think about what started to happen with pipelines, with orchestrations, when you think about some of the different tools that have been around where you can tie together as many different objects, uh, think about even Lang Chain as an orchestration platform is important and will become more important as it allows us to insert new capabilities in different ways.

Um, I often will talk about digital platform that way. It's not, it's my DevOps platform. It's my low-code platform.

It's my no-code platform. Let's just stop with what categorizing it for a moment and just say, platform. The importance of platform and what Mitch brought up, uh, and I really want people to hear, hear this, is that increasingly what we're going to see is fewer front end developers, fewer, uh, people.

I call it jokingly slinging code, and more of our people focused on engineering those platforms that are going to enable right now, it's helping our developers right now. It is helping the world as it exists right now by plugging all of these things into the bigger value chain. Um, but what we're gonna see over time is we're gonna see different types of users that are leveraging those platforms, which have more than large language models.

Mitch brought that up. These are not platforms that are only meant to have an LLM on one side. We do need people to figure out how to leverage LLMs, how to self-host them, how to put these other components on top of them temporarily while the models get better, right?

We have to have rag and we have to have embeddings and vector, uh, databases and things to help us. But those are going to get better. But we're using all different types, all different types of, of ai, and they're all going to be plugged into these platforms.

Now, one thing that Mitch alluded to, uh, is that we're actually continuing to take those that step back and look at things more holistically. How long did people talk about DevOps? And it was from code commit to production.

It was like this little segment. And what we've learned through value streaming through the value stream management, um, what we learned through, uh, Dr. mit, Kirsten and project to product and full slow, is that we need to connect all of this.

We need to connect the business information with the program and project management with information, with the execution by the different types of people. It ain't just the developers. It's a lot more humans that are tied in.

And as we get that full view, which is what they're, that these people are attempting to do, what Atlassian is looking to do is, let's really give you the big picture. We're gonna see the ability to get better data that's going to inform all of this. So every organization is start is going to need to really get a hold of their own data and start to make it available to these, to these platforms.

So that's a lot to say that. Yep. Mitch is spot on.

It's, it's, it's not just, Hey, we got an LLM. It's not just, Hey, here's how you stand it up and how you can tinker with it. We need to know how to operationalize it.

Mitch. Well, you need to be on more conversations with me. Trace that.

Well, let's get together more. Appreciate the call about it. So, so Mitch, the CEO for Atlassian painted a picture that looks something like this.

And what he was basically telling the attendees was, every software engineer or DevOps person, or for that matter, everybody's gonna have multiple AI agents. And these AI agents are going to perform, uh, asynchronously tasks on our behalf. And they will occur as I'm doing other things.

And then you and I will each have our own cadre of these digital assistants. And somehow or other, the future collaboration according to him, is a mix of AI assistance and humans working in conjunction with each other to accomplish some sort of task. And I'm trying to figure out in my head exactly how will my AI agent call your AI agent to make something happen without maybe the two of us being in the middle of that all the time.

Is that how software engineering's gonna evolve? And how do we govern that? Maybe my ai ai agents that have lunch with your AI agent figure do.

So here's what I think is interesting about Atlassian is, um, at least how do they present it to the end, end user? They're not enamored with AI as a bot or as an agent, or as a whatever, right? Yes.

They named this thing called robo. And Robo, by the way, can also connect to your Google account and mm-Hmm. Look at the things on your drive and also look at some other things beyond what's on the Atlassian platform is, think about it this way, AI surfacing things that will help you in your work.

So one of the scenarios that I saw was, Hey, I, I'd like to create a workflow that does the following things. Set this up, do that, do that next, and then handle this. And Roe or the platform would say, there's actually a, a process like that already, that trace set up.

And if you need more information, you can contact her. Would you like me to use that to create this for you? So, um, part of your workflow, not just handing stuff off and going away.

Now, maybe someday there'll be a lot more things happening autonomously than, than we do now. Mm-Hmm. Um, but that seemed to be how it was characterized.

I also noted that you don't go over into an AI tool and create your AI workflow or your ai, whatever you're asking it to do. It's right there in the interface. Yes.

There's sometimes they call it intelligence, right? Um, is there AI intelligence offering? There are, there is a place you can go click on this and I'm gonna do these things.

It's also built into the, this knowledge graph, the, the teamwork graph of saying, you know, well, what you're talking about, there's a reference to rag. And actually the trace is the person who is building rags for these products. 'cause they're part of this engineering team.

Here's the APIs, here's the places you can go to find out how to build that as part of your app. Matter of fact, there's a library of things that you can leverage Al already, as opposed to me saying, Hey, who's doing something with Rag mm-Hmm. And how can I find that?

Right? Right. That's, So, I, I think the effort is, well, I'm sure there's a long ways to go to perfect.

It is to try to make it how you work, not a query engine to go find stuff for you. I think there's some important pieces there. There's, uh, the discovery aspects.

So there really is, uh, just, uh, on steroids. It's the, the vision that was out there with the Google appliance that was rolled out into people's organizations, what a decade or more ago that were, it was going to discover things where it's gonna be easier us for us to find it. The fact of the matter is that these new technologies to help us to, to discover those things, but it also means it needs to understand Mitch's intent.

What's Mitch's intent? So there's a tie in to surfacing you and surfacing your information to allow it to discover on your behalf. Now, there's an interesting piece of that though, is that, and this is what Mike brought up for, for right now, our interactions are between us and our, our assistants, our AI assistants.

It's a, it's a relationship. You and I don't share that relationship with the same agent right now. I have my agents, you have your agents.

Uh, and in my conversations, uh, working with directly with Microsoft, working with Software Engineering Institute, talking with Yahoo, we're all seeing that in the short term, there could be more data silos unintentionally. As Mitch is working with his ai, and Mike's working with his set, and I'm working with my set, that's something that we'll have to solve for Mike, where we're gonna go five to 10 years out. Right now we're talking about AI as a tool, and now we're talking about maybe making the tool a little more robust by putting an agent in front of it for invoke ability.

And it might have a couple of additional components to help it help you a bit more. There will come a time, and the research is showing this, that AI will be delegated autonomy to do a particular thing once we get to a point where we trust it. Once we get to, and we know at this point trustability AI assurance, we're not hitting the marks quite yet.

You can, and in the same way that you can hallucinate, uh, citing legal references, you can hallucinate on code that's generated and tests that, that are created. Um, so I say that because there will come a point where we trust it enough that we will now have a team member that is an AI agent, an AI team member that is going to change the dynamic of a team. There's already studies that are showing that people are taunting with each other anymore.

If I'm hanging out with my AI buddy, why am I turning around to talk to Mitch? I don't need to do that until my AI buddy says, Hey, Mitch has got this workflow that you wanna copy. Hey, Mitch, can I copy your workflow?

Yeah. Okay, good. So we're seeing some changes there.

So imagine what this is gonna do over time. I've got one AI agent that's allowed to do one small bit of work, and we'll test that and try that, right? We'll put, dip our toes in the water, but envision what that might look like in five to 10 years where we have much more trust built up.

And where we are trying to figure out what's that teaming look like if it's two humans and five AI team members, what's that? We've optimized, think about agile. We've optimized for humans work in progress.

We try to limit that. How many things do you work on at a time? One, you take one story off the stack, we've optimized for the way humans understand and work.

Are we gonna be able to scale differently? Uh, there's a lot, but this is, I'm talking about the long, long term. Where we're at right now is where we both have described it, is we are going to see assistance that are going to empower us individually to have higher productivity.

Right? You know, I wanna run a clip here for a minute that in an interview we did with Doug, seven from AWS who's, uh, running the, uh, AWS uh, developer queue platform for them. And what's interesting about this is he kind of talks about for a couple of minutes what the relationship between developers and software engineers is gonna be.

Because from his perspective, developers don't really wanna engage with all that backend stuff. They want somebody to magically handle that from 'em. So we've been talking about shifting all this stuff left to developers for years, but maybe we're shifting backwards with the help of AI and 'cause to his point of view, developers just wanna solve problems.

They wanna write code, and they don't want to have all this backend overhead. So let's run that for a minute. Are we gonna democratize software development to the point where I can just come in and describe what it is that I want and the, and the process will just automatically be taken care of?

Or do I still need some level of knowledge and expertise? And to what degree? You know, I think the, the holy grail for any organization is to be able to come up with an idea that generates business value and instantly and freely have that, uh, be realized for them.

Uh, the challenge is physics, and we have to build software oftentimes to realize that value. So the goal has always been to, um, decrease the amount of time necessary to go from that idea to the business realization of that idea. Uh, so tools like Amazon Q help in that productivity.

You know, would we get to a point someday where you can just say, Hey, I want this, and instantly an AI agent is gonna create the thing you need and make it available possibly in Q apps. Is it one way of seeing that happen with things like line of business applications? Doesn't mean there's not, uh, the need for software developers.

In fact, it probably means we need more software developers to build these highly complex AI systems that will enable this to, to happen. But what we're doing is eliminating a lot of the mundane and tedious and toil ridden tasks that developers spend their time doing so they can spend more time on the interesting cognitive challenges of solving new and novel problems, uh, and, and building new and interesting software that we just probably can't even imagine today. So Mitch, are we getting to the point now where we think that maybe we can just get out of each other's way and let the developers do what they wanna do and we'll make it all work magically work on the back end?

They've probably have been offered help enough times, right? I'm hearing from X department, I'm here to help. I'm your AI bot.

Um, I, I, what I think what's really valuable about this conversation in your conversation, um, that you had with Doug is Tracy hit on a point of everything now is focused on one person, making one person more productive, right? How many, but how many bots can I live with? I can, I can already, I can't handle the number of bots on every tool that I've got.

Right? At some point you're like, yeah, forget about it. I can't do all those things.

You're just adding more work for me to understand how every bot is different, how it works. The, the kinda Rubicon is isn't just autonomous, it's as, as Tracy was speaking, that's one path. Um, and it's an important path.

I think a parallel path is collaboration and teamwork, and it can show up in the form. Tracy, you talked about as a team member bought, there's actually a company that was kind of working on that in the development side in the early stages. You're right.

Mm-Hmm. You said it was in development. Um, but I think, you know, it's like go far or go fast is a, you know, by yourself, go far with a team, right?

And so that's where the real productivity is, isn't just code completing my, my code or writing a code segment for me, um, or automating a setup of something for me. Mm-Hmm. It's doing that for everybody, right?

And then sharing that. So I think that's kind of what Doug is alluding to or where they want to go with this. With q um, kinda sounds like Q is Watson, but that's the oh oh seven of Watson.

That's kind of funny. Q Well, I think you, you know, bringing up productivity. One thing that we need to caution all the viewers on is don't overfocus on individual productivity, is we don't, we don't measure productivity for our teams on an individual.

Are we cognizant of it? Yeah, we're cognizant if trace is having a hard time and needs a leg up, but that's, productivity should be measured at the team level, not at the individual. There's also another piece that's interesting right now just to have in the back of everybody's mind.

If you ask people to ask them about their productivity and how things are improving, a lot of times right now it's perceived productivity because it's exciting and it's different and it's new and they hope that it will help them. And it might. Um, but the, if you truly measure, if you truly have access to when they're doing the things that they're doing, when developers are still only developing 15% of their day or less, right?

They're doing a lot of other things. So, you know, when you start to pull all of that together, when you look at productivity, um, productivity right now with some of these things, if I have too many agents that I have to figure out too many different ways that I have to orchestrate my prompts, too many ways that I have to bring misinformation in, now I own that information that was generated by somebody else and I have to learn it and be able to support it and be able to be the master of it. Productivity actually goes down at first.

So things to be aware of. Measure productivity at the team level. Be cognizant of overloading the individuals.

All right, folks, I think we're going to end this conversation here because well, it will continue in the future. My only one point that I would just advise everybody is if you're wind up being more emotionally attached to your AI agent, you might have a problem. We'll be back in a minute.

I'm Bonnie Schneider, sustainability contributor to the Techstrong Group. I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter. The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry.

Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong Research. All right, folks, and we are back and we're talking about internal developer portals. The folks who created Backstage over at Spotify had some updates that will make it easier to deploy because they're let letting you have the version that they use to download, uh, with a commercial provision versus the open source version, which, um, by all accounts is a little hard to actually deploy.

But Tracy, I wanna get started with you. I seem to remember talking about this concept of IDPs, I don't know, 10 years ago, maybe longer, and now Longer than that. Yeah, longer than that.

It Seems like suddenly it's back in Vogue. And why and how did we get so far without 'em? We didn't.

We haven't been going on without them. We're making them better. And we're merging in like platform engineering.

We're trying to make it so developers can be self-help, um, because we are introducing more friction. 'cause the more things that they need, there's more complexity in software that we're building now than there was before. I need different services.

Uh, let's say that we're using, uh, a particular cloud vendor. Oftentimes it'll limit the types of things that Mike can do, and Mike has to make a request to get a different type of service that's tagged against him. Like all of those things we're introducing friction, friction, friction, friction.

Well, what we're doing is moving, getting rid of that friction, and we're all helping and the developers in any way we can to be self-sufficient. And we're also trying to do one other thing, reduce mistakes. So if we can codify leading practices and have those as part of what we're doing for them from a self-help perspective, if we can kickstart things to be better and streamlining makes their lives a little bit better, we get software higher quality, faster out to the end users value.

It's a good thing. Mitch, do you think Backstage is emerging as some sort of defacto standard for IDPs? I mean, I see it offered almost by everybody these days, but I also know there's a couple of commercial platforms out there.

So what's your sense of where does Backstage fit these days? Absolutely think it's a defacto standard. Um, just even going to coupon, how many people talked about Backstage.

Um, and there isn't a commercial product that's kinda risen to that level yet. So for now, and maybe for some time, who knows, uh, that is the defacto. And I think partially because it's open source and it's being really engineer being invested in by the community, it's taken, been taken very seriously as well as seeing lots of adoption both by end users and also commercial offerings.

So, which is good. Maybe it'll stay that way for some time. I, that I can't predict, but we'll see.

I'm sure someone will, when we start thinking about how we tie it to a platform like what Tracy was talking about, then I think we may have a differentiator that a commercial offering, you know, like a GitHub or someone like that, or an Atlassian, um, has the potential to do more and less integration work, um, by the people implementing Open Source. So we'll see where that goes though. Yeah, I think that'll be interesting as we see the convergence of the two.

Uh, I mean, it, and, and quite frankly, best Stage has been supported by Spotify. So it, it's a little bit different when we talk about open source, right? Open source that has been, that has come out of a, of a corporation and then is made public, um, is as a different level of maturation than something that's coming out of Mitch and I have a great idea.

And we get together on a Friday night and we're coding, and then we start to get, uh, accelerate. There's a different level of maturation. So it's already, uh, at a, at a different level of reliability, a different level, level of capabilities, um, than we would see then we then we definitely see coming outta some other areas where people are attempting this.

But it really is about that reducing cognitive overload, making it simple. This is a, we're trying to make it everything depends on the developers these days, doesn't it? Gotta make their lives, gotta make their lives easier.

So can, And maybe it's something that gets donated to the CNCF for, you know, when it kind of takes on so much that it's bigger than Spotify, at least in what their recent were. Well, well, maybe. We'll, There was some conversation about that, wasn't there reason?

Yeah, yeah. That they might do that. I think, I think Backstage is already over at the c ncf F but Mitch brings up an interesting point in the sense that, Yeah, it did go there.

Um, The thing that makes me scratch my head here is, so let me get this straight. We have an instance of backstage that's open source, but now we're gonna get a better version of backstage from Spotify that is easier to deploy and maybe, you know, it's more opinionated, shall we say. And then also they are gonna provide enterprise support for this.

Now I'm like, last time I checked Spotify was, you know, essentially a music digital distribution company. So I'm not quite clear what they're doing in this space, and are they getting ready to spin this out into some separate company, or how do you think that might play out? But, um, it's unusual to me to see this level of activity.

I mean, the only other thing that seems similar to it is maybe Intuit in Argo, but, um, is that a sustainable model or what do, what do you guys think? Well, Think, think about it from a, a slightly different perspective. For how long have we been quoting and holding up as that unicorn example things that Spotify does.

So if they're known in the industry as thought leaders, if we're already examining their methods, their ideas, their concepts, the Spotify model for how we're going to organize our people and our processes, isn't it a natural next step for them to bundle up their goodness instead of having vignettes and, uh, you know, conference speaking engagements? Isn't it, isn't it natural for them to bundle it up and actually make some money off that? So in my mind, it actually is a natural next step.

They've got a, a very crack group of engineers, software engineers, they have great leadership engagement and buy-in to make these things happen. Oh, isn't every organization really a tech organization these days? What do you think?

Well, they, they are, I mean, but I guess that's the, the mantra now. We're all software companies, right? Um, it's just, I think it's a matter of where the company wants to go.

And do you see yourself investing in supporting a backstage and commercializing it? And yeah, maybe you spin it off or maybe you do what Lyft did with their tracing. I can't remember the, the name of the product, but they spun out a, a tracing open source, put it back into the CNCF.

Um, and, and because frankly it will get broader adoption probably that way. Whether you really have got a commercial model for backstage, don't know. I mean, you there, maybe their market testing as part of this to decide if they keep going or they, they just turn it over and let other people do it.

Yeah. Well, Tracy, you bring up an interesting point. Is there such a thing as, okay, there's the Spotify way, is there an alternative Netflix way?

And are we starting to see these kinda, you know, schools of thought emerge? Kind of like in the world of art where you have different schools of I share a philosophy. We've, But we, but we've always had that, we've always had different ways to do software engineering.

We've always had different ways to get after adopting agile processes in, in our different domains, right? Our different business areas or different industries. We've always done things different ways.

That's okay. It doesn't, it just doesn't mean that there's going to be, um, only two different political parties and you either have to be a meta or a Spotify, right? It doesn't mean that you have, those are the only, they're going to be thought leaders, but we're also seeing a really awesome surge from the individuals.

We're seeing a really awesome surge because we have the availability of communities, because we have the ability to hop on a, you know, tech strong gang and have a conversation. I could be a sole proprietor and have a really great idea and be able to, to propagate that out. So I think it's a yes, and I really do.

Mitchell, we talk a lot about developer productivity these days, and this too makes me scratch my head because I get that we wanna reduce the cognitive load and that's all great, but it doesn't necessarily translate directly into my mind that a developer's gonna spend more time actually writing more code because well, um, inspiration needs to strike and for all we know they're just gonna spend more time playing games. So, um, how do we kind of measures developer productivity and something that's meaningful here? 'cause we're doing all this work, but I'm not quite clear that there's a KPI on the other side of that thing that says we succeeded.

Yeah, and I'm, I'm the same school of thought as Tracy of, I don't think there's a productivity measurement for each developer and saying, how many lines of code did you write? Oh, please don't code lines of code, sorry. Please don't ever bring that up.

Flashback there on flashback. I think it ultimately, I mean, it ultimately, and this is what drives me crazy about, about kind of technical or IT goals and metrics and KPIs is so what we're delivering code to production four times a day. Why is that important to the business?

Why is it important to the business? What is it about doing? Or maybe that's not important.

Some other things are more important. My point is, I think ultimately it's not about a developer or developers and total productivity. I think it's about the output.

Mm-Hmm. The teams are producing the quality, the security, and the velocity of that, and their ability to respond when they need to respond. Sometimes having that, I can deploy four times a day, but I don't, the only time I really do is when I need to in a security incident situation, Mm-Hmm.

Where I've got something that's gotta get, really get to market. It's kind of one of those, I can do a three pointer, but I'm really under the basket kind of, kind of person, right? But I can shoot three pointers when I need to and make 'em.

So, uh, the productivity Mike, I think is usually about taking toil off of people's, uh, uh, their agenda, you know, platform engineering and helping developers not have to set up environments and making it easier to pick things, nowhere to go pick it up, et cetera. I think that's what it's about. Just making people's job easier is another developer productivity label.

I just wish that we, I've been in the software industry my entire career. My entire career. Why are we only talking about the developer?

Yeah, exactly. Why are we talking about the developer? What about my human factors engineer?

The person who understands what the interface, the external needs to look like? What about the functional experts? We still have those.

This isn't software these days is not just Mitch sitting down with the end user and then him pounding it out and in the voila it's there. There's a lot of other humans involved. And so I, at times, I think that we are too focused on the developers as a group.

Um, now granted somebody's gotta build the code that goes forward, but there are a whole lot of people, there's a whole supporting organization around that developer. So yeah, if there's a whole lot of us invested in what this one person can do, think of it like an Olympic athlete. There's a whole core of training people that are around them to make sure that that human gets the fastest race right?

Or gets the best measure when it comes to their Olympic competition. But though we gotta make sure that the others are included in that, and they make a difference to productivity. If an Olympic athlete doesn't have all of the attention that they need, if they don't have the sports, uh, physical therapists, if they don't have the sports medicine people, if they don't have people who are watching everything that they do and analyzing it in order to help them get better, well they don't get any better.

So there's an interesting dichotomy here. Um, but yeah, I like to look at the developer productivity framework that Nicole Forsgren, uh, you know, she's from, she's with, uh, GitHub of Microsoft now, but she came out with this in 2021, and I recommend taking a look at it. Uh, it does help get after a number of different elements.

It's not just slinging those lines of code. Uh, it includes some human elements as well. And we're actually talking about expanding it tad in trust from one of the conversations we've had before, Mike, about what happens as you're adding in generative AI tools and techniques.

And we already know that generative AI tells fibs. So what, what's it gonna mean in the future to your productivity? I'm trying to help you go faster, do better things, bring value.

What happens if I can't quite trust that one tool? I think it convincingly tells bibs is the bigger issue. Um, Let me ask you like a really philosophical question then.

For a while there, we were always talked about, you know, software development and the factory, and did we lose sight of the simple joy of software development and the fact that it's more of an art, and yes, we want people to be more productive, but the the reason for that is so that when inspiration strikes, they can do something about it versus Mitch's point about, you know, no, I'm not gonna do that 'cause it's gonna take me an hour to set up the development environment. I mean, so do we need to just return to the joy of software development? I would hope that we had never gotten that far away.

But the, the term software factory actually came up in the seventies. I think I read about it in a RAND report that came out, honest to goodness, somebody sent me a scan and it's, it's printed, you know, it's, it's courier font on paper, uh, and it has software factory. We're not building the same thing every day, but we are using the same processes.

So the factory analogy should be around the process, but what's floating across that assembly line one day, you know, it's a, it's a John Deere tractor, and the next day it's a pack of UNO cards. I mean, there's very different things that are flowing across those assembly lines. So I think we do the, the factory mentality, it's unfortunate it's starting to grow into like an ecosystem, um, where the factory is all the things that you do, all the people that you need, the platform, the underpinnings, the infrastructure as code.

They're starting to talk about factories as being all of those things as opposed to that group that gets the microscope, uh, on top of them all the time. Yeah, we have to make sure that it's a, it's all of our jobs, but especially the developers now, it's not just art though. I would say that they better know the science too, if it's gonna work and be, uh, sustainable.

All right, folks, I think we're gonna shift to our next topic, but I would just say maybe Cyndi Lauper has it right all along. Developers just want to have fun. 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, 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. All right folks, and we're back for the final segment. And we're talking about golden templates and the rise of platform engineering, and we've been chasing templates as long as I can remember in it, there was always this notion that there would be this perfect thing, and if anybody messed with that, we would know and all the anomalies would be discovered.

And I think we're now trying to apply that concept to platform engineering. com talking about the pros and cons of that. And part of the cons is, well, we wind up becoming inflexible in our minds and we can't extend this thing.

So, um, let's start with Tracy, but how do I kind of manage this platform engineering thing and, and not make it sound like the revenge of centralized it, which is the whole reason we went to DevOps anyway to get away from, Well, I don't think that was the only motivator for, for DevOps, but we're seeing that we're on a pendulum swing, right? It's centralized, decentralized, centralized, decentralized. The key is to be somewhere in the middle of this.

So you want to be, as you wanna dictate as much as is, is necessary, but as little as possible. Like, there need to be core standards that you don't compromise on, but you shouldn't be just making all of the decisions at all times. And there needs to be variability, but that comes from having some smart governance and laying some boundaries.

I, I need a team to pull down a template. I need them to look at this and say, you know what? I need to inherit from this.

And I say, you know what? Great adhere to these standards and go ahead and extend with those other things that we've talked about, go and do. So there's, there's a balance of it.

I do think that we run the risk of getting back, and this has to do with staffing. We run the risk of getting draconian, of becoming that old school rigid it because we don't have people that have enough time to pay attention and have the conversation about it. If I don't have enough time to have a conversation with you, Mike, about what your team needs are, I'm gonna say no.

Here's a template. Follow it. So, Uh, Mitchell, I think Tracy just described something that sounded like a benevolent dictatorship.

Is that where we're going with this thing? I mean, how does it kind of sound to you? Well, um, spoiler alert, I'm getting up on my, on my soapbox here.

Um, so a a and it, it's not been this way for a long time. A mistake we continually make is we treat software as a fixed object, as a a, something that stays static for a while. And we're in a world where it, it's a fluid, it flows, right?

Whether you're writing. So while we're writing microservices or the SaaS service you're using is updating itself and you're not necessarily where we live. We live in this ecosystem that's constantly changing.

Um, and even things that get, you know, burned into chips for embedded systems, those have ways of being updated and they're working within, you know, fluid parts of the system. So the idea of a gold template goes back to the gold master days, right? 3 point AC seed seven, and that's where we're gonna replicate a million times and send it out to our customers, right?

This, we don't wanna make that same mistake in platform engineering. It's not about a gold master. If that gold master can't be easily changed and, and flow and, and uh, let out into the places that it's being used, without developers having, or others or testers having to jump through hoops to apply it, we failed.

It's not just about getting the master the template and starting, it's about continuing working Mm-Hmm. With a changing object that's adding capabilities. It's simplifying it, it's making it more operational.

It's adding tracing capabilities for our observability system. It's addressing security issues that might be part of that or other parts of the system. So, you know, as you can tell, I have a strong opinion about this.

Stop thinking about software as a solid, it's a fluid. And if you can't easily change, it doesn't matter what you've done. All you've done is one step in a a thousand steps that you really need to make more productive, uh, for everyone.

So think about the continuum of how that software's gonna live and how it lives, breathes, gets updated, increases its capability or whatever might happen to it. That's what the real value of thinking about platform engineering is how you help with a lifecycle. Just like the lifecycle of an API, it's not the API right now, it's the life.

It's the API as it was that's still running. And the API is it, it will evolve to, it's not a static thing. Well, and we always used to use the term software development lifecycle.

We used to talk about lifecycles. Um, to your point, the goal of a template should be to help not harm, right? That whole concept of do no harm enable fluidity, right?

There's there, you're right that we need to not, I'm gonna keep coming back to that draconian thing. We need to not set up these bureaucracies, but we do it. There are val, there is value to providing quality jumpstarts.

There's, there's definitely value there. Uh, and tie this back into the conversations about developer portals. Tie this back into conversations about platforms being provided.

And there can be goodness, but I I, I saw, I was working with a very large, um, government agency that was not in the DOD side of the house, in the public sector side of the house, massive. And their templates were so complex and so locked down that for you to get an image that would juice, it took nine months. I want you to hear that.

Nine months to get an image stamped, because it had to go through these workflows and validations and approvals. It was a template. It was, was, it was this entire golden image concept.

So help done hamstring. And it was out a date two weeks into that nine months, right? And that, which was another one of the problems, right?

Because they had a change review and evaluation process for that. So it, it, they had no plank to go, but a spiral in time. Uh, it it, that's all that it became.

How do we tracing get developers to buy into this? Because some of them, and I don't mean to offend, but some of them are, shall we say, you know, agile methodology, fundamentalists, and they think that they should have all the tools, decisions and, and, and, and they're not inclined to give up control. So how do we get them to kind of think about the greater good here?

Two ways. First of all, the developers are not the business owners. They're not, they work for you.

So do they get to make all decisions? No. So when they're hired, when they're a part of your organization, you need to have the discussions on, on scopes of autonomy.

These are all the things that you get to decide, these other things you don't get to decide. So it's okay to make sure that your entire organization understands the scopes of autonomy. Now, the other piece of this is, well, how do you get them to buy in?

How do you entice people to, well, that has to have value to them. So to Mitch's point, it has to bring them value. Um, are you gonna have a cowboy out there who just doesn't wanna do anything that you say?

Sure, you're gonna have to deal with that. But bring 'em to the table and don't push things out. Don't do what IBM did 20 years ago.

And what they call this, the Blue books, they dropped the coding books on the table. This is how you will do everything that you do. Um, don't do that.

Make them a part of this. You wanna a template that people will adopt, make it so that they can see it, make it so they can have a pull request, they can submit a change against it, make it something that they have co-ownership of. You have co-ownership, you have input into it, you're gonna use it.

Mitchell, do you think that the average DevOps software engineering team understands how to have a conversation with developers? Is this kinda like, you know, Venus and Mars and Republicans and Democrats, or, you know, how do we kind of get there? Isn't that why we have DeVeres now?

You know, it's, it's a, it's again, kind of every developer. There's not a uniform every developer, right? We're all different.

We're all humans. We're creative. Um, the, the, the rogue cowboy, you know, that Trace talked about, you know, don't, don't stick 'em in the maintenance job of they've got this box to work in, right?

Maybe set them off on the, we want to try, here's three engineering problems we need to figure out for where we're headed. Go work on some ideas and we'll see what we adopt from that. Maybe that's the best use of their talent and skills.

And take the person who's really good at solving the complex engineering problems of how we're doing with our code today. And, and address that. I think, I think there's the individual adoption of, you know, templates and standards and platforms and things like that.

There's the team adoption too, right? So I wouldn't go to one person and say, Mitch, you really need to step up and get on board and be a team player and use A, B, and C, and then you can play around with the Z. That's where you can play.

I think you do that as a team. Look, mm-hmm. Hey, we all, we want to decide together.

We're working with this team to help us do this. Uh, that's what they provided. Are we good?

We need to give them some feedback. Great. Okay, now let's go forward.

That one's that we've all solved and we've agreed together that we can do that. I think you can go a long ways to helping overcome some of the individual resistance to that. Mm-Hmm.

Um, at least that's how I would approach it. Tracy, do we therefore need all our DevOps leaders to, uh, become quasi experts in organizational behavior and psychiatrists and understand what motivates these people? No, I don't think it has to quite that deep that we do need to be aware, right?

If you're leading people, then you have to understand people, right? So yes, there are people skills that are relevant. There are, uh, there's, there's quite a plethora of good information that's coming out now to help people be better leaders, to be better enablers.

Um, especially in technology. When we think about, you know, some of the new, uh, materials that you're, that, that are coming out from Textron that help leaders, uh, and at different levels of leadership, that doesn't mean I have to be a c-suite leader. I can be a leader on a team of five.

Uh, and I do need to understand how to get along with people. I mean, maybe this goes back to the elementary school. Maybe we need to have fewer participation ribbons and maybe a little bit more learning how to get along on the playground.

There you go. Well, let's bring it back full circle. Mitch, what do you think about like, you know, an AI leadership assistant, right?

Gonna help me sort all this stuff out and say, you know, Hey, there's something you should be thinking about here that goes beyond just the software engineering task at the moment. Oh, you mean the AI overlord? Oh, yes.

That's what we need. That's what we need. I think that we should put all of our corporate information into an externally hosted large language model.

Tell it that we want it to act like a CEO of a major corporation and tell us how to behave. And then just read it out loud and then that becomes yours. There you go.

There you go. Done. Done.

Makes me think of the computer Deep thought and hitchhiker's guide to the Galaxy, right? What's the meaning of life? The universe and everything.

And it takes, you know, eons to solve. And the answer is 42. 42 Mm-Hmm.

What was the question? I forgot. So I don't know.

But 42 is the common answer in my household. If you dunno what it is, you just say 42 42, nobody even has to ask a question. You just look up 42.

Well, Let's think about that for a minute, Tracy. I kind of like this idea of what do you think, uh, the probability is that the C-E-O-L-L-M is gonna hallucinate more than our current CEOs? Well, that's a whole nother thing.

So here's what I would say. I'm not comparing the humans to the models. If I compare the accuracy of the model, it will depend on the tuning and the data, the quality of the data that went in.

So depends. Is that a little bit of projection going on there? Mike?

Are you talking to somebody? You and I know. No, we need to bring him back on Here.

I have a lot of experience working in many companies, and No, I do. I'm just kidding. I know you're not.

We, We are all humans and we all hallucinate from time to time because we want something. I know nothing. I know nothing.

And a lot of it just comes to, you know, we, we wanna impose our views on the world, and we think that, you know, what we see is the way it is. When in reality there's a, there's a, a, a gulf between what you see and what's real. And so sometimes you make decisions based on what you feel more than what is real, right?

And We all do it. But my, I have this, uh, my, my, there's really getting a theory about it. My view is the multiverse is everyone's individual mind is one dimension of the, of the multiverse.

'cause none of us think and see and experience this the same way. So you have a team of five people, there's five universes that are happening all in parallel. And we're trying to figure out how to help all of us to kind of march in a similar direction or, or share a common goal or whatever it is.

So the reason why, why I, you know, kinda came up with that model is like everyone has other things that they're doing. Mm-Hmm. Thinks that you, there's no, there's no separation of life and work.

You don't turn off life and then come into work and just think about work, right? You bring all that stuff with you just like you bring work home, right? Or whole people.

And, uh, you know that that's my multiverse. Now, is that ever someday the, uh, matrix? Well, I guess that could be, you know, that's, that's been around.

This is we're getting to the point where we should be popping open a, a bottle of something to go along with this, this conversation. Well, I am in Rocky Mountain High in Denver, so, oh, there you Go. See, you're having mimosas.

Is that what I do wanna ask Tracy? One question here about all this. So I mean, we tend to focus on the negative, and yet if you look at all the things we have accomplished, mm-Hmm.

Doesn't it bother your mind that give it all the hurdles and obstacles and things that are getting in the way that we managed to do as much as we've done? Um, I talk about this, uh, there's the re one of the reasons is that as humans, we care. Mm-Hmm.

Why are we able to deliver stuff? Because we put in the herculean effort, because we stay over the weekend, because we sleep under our desk because we have pizza delivered. Um, we don't want people to have to sustainably put this on the backs of their goodness.

And so that's a, yeah, we have done a lot of good stuff and what we're seeing on the horizon, there's groundbreaking potential, groundbreaking potential with some challenges and some limitations. And it will get better as long as we remember that we're humans. That there, the whole piece of this is for a while we kind of forgot about the humans and, uh, tool focused.

Well, now we're swinging back to remember maybe the lockdowns, were good for that. Maybe all of this is coming to an intersection right, at the right time. So yeah, we've done a lot of good stuff, but we had to sometimes do some Herculean stuff to get there.

Let's make it be a little less painful. Let's make it more enjoyable. All right, Mitch, last word here.

Well, you know what, it's, it's ultimately about people, no matter how much is part of that equation, right? Mm-Hmm. So I think we can't forget about that as much as we automate or as much as we might have assistance or much as we might have, um, you know, uh, autonomous things being done for you.

There's people in the system and that's always going to change than just having something that can be reliably done. Or maybe something that hallucinates that also is a digital, digital something, right? So, uh, we can't forget about that.

And that's why I don't think any of these answers to these questions about is AI gonna replace this? Replace this. No, it's not a black and white equation, right?

There's so many paths to this of how this will happen. It's not this or that. Alright, folks, you heard in here, the glass is always way more than half full.

So plan accordingly. Drink up. All right.

Hey guys. Hey. Did someone say drink?

What, what? Where's that mimosa? Well, let's not let software engineering drive people to drink.

That's just not a good thing. That's true. There's Our new, that's our new motto and got a t-shirt coming there somewhere.

All right. Hey folks, thanks for watching the latest episode. We enjoyed the chat.

We hope you did. Too. com when he, he'll be back for the next few episodes.

But hey, Tracy, Mitch, as always, thanks for being on the show and sharing your insights. Enjoyed it. Thanks Chris for being with us.

It's Always fun, guys. Always Did.