Prioritizing Developer Productivity – Markus Eisele, Red Hat

This is Textron tv. Hey guys, thanks for the throw. We're here with Marcus Islay, who's a senior product marketing manager for Red Hat, and we're talking about developer productivity.

Marcus, welcome to the show. Thanks, Mike. Uh, pleasure to be here.

We've been talking about developer productivity for years now, but it seems like the conversation has been elevated in intensity, and we hear about initiatives such as platform engineering and all kinds of interesting things that are going on. From your perspective, what's driving this level of conversation today? It seems like the whole thing has just been elevated and everybody up and from the c i o to the c e o to the developers themselves are talking about it.

Yeah, I think there's, uh, there's various different motions leading us into the direction of talking about developer productivity. One thing for sure, if we're looking back into the last 10 years and how the complexity of technology itself literally exploded. Like 10 years ago, you had a choice between three major platforms for enterprise development.

It's all been pretty standard APIs. You got like a thousand pages book, you got a little bit of experience, and you were able to successfully develop a solid handful of big enterprise applications. And, uh, if we're looking at today's landscape and landscape is, is probably a good, uh, good keyword here.

Um, take the C N C F landscape, for example, and look at what's possible on Kubernetes and the number of choices developers and architects and companies have today. For all the individual functional and non-functional requirements of applications, this literally exploded. So as a full stack developer today, you, you, you're no longer just responsible for implementing business logic.

You are literally responsible for herding cats. Like everything that is relevant for your application, you need to need to pick and choose and make the right choices, ideally, that are even future proof. So that complexity part for sure is, is the biggest driver of questioning or talks around developer productivity.

And, uh, I do also believe that the, the second issue is that we actually do not have enough developers. Like, um, skillset is, is becoming incredibly hard to find in particularly in all these modern cloud native applications, stacks and technologies and even cloud providers. Um, it's, it's becoming increasingly hard to have the exact right skillset as a developer coming out of university, um, where you still basically learn c plus plus and Java as like the foundation of a solid programming career.

Did we push too far left because it seems like we're asking developers to have a much higher level of cognitive load to go build an application and it's, I'm not sure that they're spending most of their time writing code for applications. It seems like most of it is just been supporting the environment. Exactly.

I mean, this is the perfect keyword. Um, we talk a lot about cognitive load, um, and I think what we all mean by this is, is basically juggling too many things. Um, it's no longer just the laptop, your little environment.

It's, it's literally from applications to containers to pods and ultimately to Kubernetes in production. And, uh, unlike years ago where this took like a tar file and a bunch of bash scripts and a couple of VMs or target service, this went like all in global regional. So how can we, I, I think the question that needs to be answered, um, today, um, and that is probably the, the most pressing question is like, there's, there's very good reason to have the separation, the choice, the, the flexibility and technologies, but there's also, like I, as a developer, I, I really wanna just implement business logic, right?

So how do we, how do we close that gap? Literally how can I as a developer be productive, implement my code while still being able to manage the almost overburdening complexity? So that's kind of the motion that we're, that we're all seeing and that we're all trying to solve.

Has this slowed down the transition to cloud native applications, which are inherently more complex, at least it seems to me just to build and also to manage for that matter, but has this become an issue that is kinda resulting in a lot of developers slowing down the pace at which they might make the transition to that because frankly, monoliths are easier? Yeah, I wouldn't even say it's, uh, an architectural discussion at that point. Um, I mean, our industry as a whole obviously isn't questioning the, the target infrastructure a lot anymore.

We're talking cloud, we're like talking a lot of Kubernetes. That's, that's a given. So the underlying complexity did increase no matter what, if you are choosing cloud native microservices, event-driven architectures, or if you are choosing monolith micro lith, what, whatever you want to call it, like the, the software architecture itself, which used to be a very vibrant part of just software development projects, um, ki kind of isn't, isn't really making a big difference anymore, right?

It's everything around, it's this staging is how do I get my software into production in a reliable way? Um, just think about highly regulated environments, for example, where you still need to have these checkpoints but also wanna have all the automation included. Like there's, there's still no matter the architecture, um, just a lot to be taken care of.

And ultimately what I think is it slowing developers down, I don't believe that what's ultimately happened is that companies are slowed down. So all these digital transformation initiatives, all these new features that we're all like eagerly looking for in our online banking apps, all this is not coming at a pace that we as like end customers would expect it because businesses are not not able to deliver, um, as swiftly as they'd like to deliver new features. So developers are probably still giving their best, and I do not believe that architecture choice ultimately makes a difference here, but the overarching output that a company can achieve that's for surely slowing down and could definitely improve.

I feel like sometimes developers are talking out of both sides of their mouth, right? On the one hand, they want the process streamlined, but on the other hand, they want maximum flexibility to use any tool that they perceive that they wanna use whenever they want to use. So how do we strike a balance between streamlining processes and making things reasonable to manage and developers feel for, uh, they're right for you?

Innovate That, that make me, that make me honest, make me laugh. Um, I I love how you're, how you're phrasing it. I mean, flexibility and choice is basically what, what is the biggest part in terms of creativity, right?

I mean, not just taking a business problem and describing it in a machine readable way. Um, ultimately it's also like playing with new things and making the right choices for, uh, the right problems at hand. So how, how do we, how do we do that?

I think, um, I like to phrase it as guardrails. So what developers really need to be productive, they need to have an avenue of approved technologies, an avenue of a path, something that they can pick and choose and mix and match for the problems at hand. And honestly, if we're looking at a specific industry, for example, uh, let's randomly pick automotive, um, there is a certain problem.

Scope is in the mind of everybody in a specific department, right? So these guys don't need to like, solve e-commerce problems in the next week. They need to solve like how to build cars.

It's, it's always focused on one business problem. So the, the technologies and choices and solutions, um, should have been quickly narrowed down already to a solid set of proven technologies that ultimately help. So experimentation in mature industries shouldn't be the biggest challenge.

The challenge is to combine the available blueprints, master architectures, references in a flexible way, giving developers the velocity they need. Um, so yeah, I, I think I like the word guardrails. Um, and I'm talking a lot about it.

Um, when I give presentations, for example, We hear a lot about developer portals, and this is not a new concept, but it seems like we're hearing a lot more about them these days. Or is that the mechanism that we're using to strike the balance? Is that how we're gonna present people or developers something that has those guardrails built in?

I think it is a good approach and it can work. Um, ultimately it's always three big topics that every really highly velocity software development project needs to, needs to look at. So first and foremost, there's culture processes, people, there's technology of course, and, uh, there's the methodology underlying that that is implemented, right?

So if you have a team that operates in a modern, flexible methodology, I'm trying to not just use keywords here, um, but some team that actually knows what it takes to develop a bunch of services, um, put them into production and even maintain them into production, they already operating on a, on a very complex stack. And onboarding new developers into this scenario is, can be very tricky because we can all all imagine how many technology layers will be involved in, in such a, a project. But, uh, just think about having a, a single place, like an internal portal, a website, intranet site, whatever you call it, where all the information that team members need to achieve their goals ultimately are collected altogether.

So if you wanna see how your service x, y, Z is doing in production, you just click on the observability link and Grafana opens up and you can like look at all your services. Um, and obviously you're already locked into that, right? So there's no need to even REIT indicate because it's all single sign on, ideally all the way, at least to the development clusters, maybe even all the way into production.

So yeah, that concept is new and we've seen a lot of these hand built, um, in many customers it's mostly intranet sites, it's mostly documentation centered, which was a good first step. But with the advent of something like internal developer portals as maybe even an implementation of Spotify's backstage, um, it, that is something that carries this concept basically to the next level by allowing specific infrastructure plugins, um, to be used or having a specific format for tech documentation or even a, a component catalog where you can have all an overview about all your pieces of your, your software, right? So I, I think it's looking at it as one of the dinosaurs in our industry.

Um, I I think it's a, it's a good progression. It is something that can ultimately help. What is the role of the DevOps team in all of this?

'cause in theory, they're supposed to be automating processes to improve developer productivity. In practice, we see a lot of bottlenecks in these workflows that developers encounter. So how do we kinda identify those and have a conversation between those software engineers driving DevOps and the developers building applications?

Yeah, that absolutely not my favorite topic for so many reasons. Um, DevOps is completely overloaded, and there are so many opinions about what these teams should look like. Um, I'm Kemp complexity exploded.

We all are in the same team, so we need to have a DevOps mindset. So I like to, to look at it from a process perspective instead of like, this is the DevOps team. That, that sounds to me like this is the next iteration of an ops team that just sits behind some barriers, right?

What we want achieve is a fully functional team that has all the tools, uh, at hand to actually do that day-to-day job. So I think what, um, what you read a lot about these days is instead of DevOps teams, um, you hear the, the term, uh, platform engineers or platform teams. So basically, um, not thinking about the end product that developers work on, but thinking about the developer infrastructure.

So basically the tools at hand that developers need for their day-to-day jobs. And these platform teams have one task at hand. They need to make their development team successful.

They need to deliver everything. These guys need to be successful, um, tooling, integrated developer platforms, um, internal developer portals, however you wanna call it. So I think, um, that's what I meant.

It always takes like three pieces to, to solve that puzzle. So have a DevOps mindset, have a product approach to the tools that developers need to be productive and put all of this to work to fulfill the business goals of the company. And this is where we get a lot closer, um, back into developer productivity because if you are actually implementing this correctly, this is the point where you gain your velocity back, where you can stop worrying about choices you make, you still have choices, and if you need to twist anything, you still know how to do it.

But I'd say 80 20 perreta rule, um, it still works in 80% of the cases. And, and this is what really is the power of deliverables, right? So this is where we started to see software developers focusing on what they do best in the speed they want to do it.

Do you think at some point that AI might come and save us from ourselves here? Or what's, how's this all gonna evolve? Yeah, I wish, uh, I knew that, um, I'd be rich by now.

Um, I, I personally, um, do believe that AI is, has some very interesting angles to it. I mean, I've been playing around with Jet G P t, DevOps, G P T or whatever versions, uh, out there right now trying to improve various parts of a developer's lives. And I have to admit, it's, um, it reminded me a lot about intelligence source codes, searches, and like predictive helpers like this, this little wizard sitting on my shoulder trying to help me do the right thing.

Um, that's a ton of potential. And again, um, if you look at our industry, um, over the term of like many, many years, you'll realize that some trends come back. I'm not saying AI comes back, but we had some like intelligent searches and, uh, code completion, uh, iterations before.

And I think AI for developers will start over in exactly that direction. So taking away the mundane tasks, taking away the need to open that thousand pages book to look for the a p I calls and how they need to be implemented, and maybe even making a suggestion. So, and like 80% of the cases, um, if you are writing this line of code and that line of code, uh, your a p I call might be prefilled with this.

So I, I think it's all about being more efficient with less stack overflowing. Um, and I'm, I don't even distantly want to b***h about stack overflow because it's still the holy grail of information that our community has. But, uh, this is exactly where AI can, can play a big role.

So giving me a starting point and helping me to like make this onboarding curve as short as humanly possible. 0 whenever I have the right large language model and tooling at my capacity. All right, folks, you heard it here.

Things are gonna get better, but frankly, if you wanna really think about this, you might wanna start from the developer and work your way back in because if you make the developer more productive, that's only the metric that anybody really caress about. The rest of it is just the symptom as they say. Marcus, thanks for being on the show.

Pleasure. Thank you so much. All right.

And back to you guys in the studio.