DevOps Intelligence – Jaime Jorge, Codacy

This is texturong TV. Hey guys. Thanks for the throw.

We're here with Jamie Jorge. Who's CEO for Courtesy? They just raised 15 million dollars for something called devops intelligence.

We're going to dive into that Jamie. Welcome the show. Thank you so much for inviting me.

All right, what exactly is devops intelligence because some people, you know, once they see that word intelligence oxymoron comes to mind and they're kind of like, you know, what does that mean? Exactly? So it's through what devops intelligence is and should be It's excellent question.

So, you know, when we started a company nine years ago and start serving some of the most exciting some for development teams around the world. We came across a necessity and necessity of insight inside in the way that we're developing software is is the quality of the products that we're developing good enough. How are the processes by which we bring these these products to Market?

Is it healthy enough to sustain a great culture for our Engineers as well? And so what we're trying to do here. I'm really also using the overload the term intelligence is to collect all these insights into one unique platform.

So our products and solutions today help developers across the world, you identify problems and software but also Solutions and improvements in in their processes. So intelligence Trudy for us is a collection of insights. There's nothing more there.

How do we collect that data because we have all these tools in the pipeline. They all generate data. There's a massive amount of data.

How do we make sense of that and kind of organize it and then find some way to actually apply some analytics that surfaces what people might consider actionable insects. That's a great question. So the way that we do things is is through very important use cases that we gather.

So for example, when we're talking about code quality we've extracted and we continue to analyze code at scale and we build essentially a great database of results issues improvements test coverage issues code application on every single commit in photographs that people are producing and so that is essentially leveraging all that that we already see existing in repos and already and see ICD pipelines. We're putting that in presented in a good actionable way integrated into the workflow. So we're talking for example of things like a new product polls.

We're integrating already day-to-day exists that people are not paying attention. So just adding points of the different life cycle of devops into one cohesive dashboard. So it's just leveraging and showcasing elevating the right metric the right.

And this issue has been around for a long time, but it feels like to me the core problem was always the developers were like the data you want me to enter into this system of yours already existed my tools that you should find some way to automatically pull it out. So have we gotten that point now where all of this happens in a way that is not intrusive to the Developers. Correct.

So so for us is extremely important that you know, as the number of tools and companies and devopsis continue to increase as continued increase exponentially, you know, it's the the men's for Automation and seamless integration is higher than ever. And so we encoded see our high really really big Believers that we should not be intrusive. We should be a companion should be another part of the team.

And therefore we shouldn't ask you to do any bookkeeping or any management or sorts and so yes, sometimes there's a little bit of a cost of integration but also pilot from that onwards that's how we believe that things should operate. How do people use this tool today? Because there's a tendency sometimes when you get this level of analytics to try to turn everything into this quote unquote Factory experience, but then the developers kind of rebels.

So how what are the best practices for using this data in a way that is constructed? Excellent questions. So um in both our Solutions, the the secret is everyday a little bit.

So we don't believe that you should wait. For example, when it comes to Quality, you should just wait into a moment in your Sprint whether those are you know, every two weeks or every month or a quarter before you release to just take a look at quality. We think that you should always be on the lookout for improvements and paid that technical that every little amount possible.

And so that actually decreases a lot, you know, the big difficult You know fearful components of of change and so as we think about our second solution pulse that aims much more engineering performance in a culturally healthy way. We think that should be a good every week every two weeks for an engineering team either that is a manager or tech leads. Sometimes the director as well or even VP to look at the metrics of the team or the whole organization.

And so we think those timings are excellent for people to have a good understanding of their engineering performance. How automated can all this get I mean, can I get to the point where I might see that a particular? Step in the process is more cumbersome than others and can I automatically adjust that or was that always going to require some level of manual intervention?

But once I have your insights, you know, what do you think is going to be the level of comfort that people will have what automating a response? That's a really good question and and to be very direct. We don't automate any any Improvement specifically we talk about processes and and and high level metrics such as deployment frequency only time for changes.

We think that because we're always dealing with humans unless let's say copilot scales into an unseen and unexpected scale in the next few years. We're always gonna be dealing with humans producing software, right? And so that given that is a very human element.

We think that there's always require a lot of attention intention and and Detail in changing the processes. So we're we We're looking at teams today in their problems today and their problems today is one of understanding. They don't have full grasp on the on where they should be improving next.

Whereas many of their peers in the Departments have tools to measure and understand the quality and performance of their departments engineering many times, you know lacks the suite of tools to do so and so we're combining that with with a culturally healthy approach to do measurement and so we are not trying to up automate we're trying to help identify so that people can make decisions so ask me again in five years see where where we are. You are collecting a lot of data. Are you going to start throwing an algorithms at this stuff?

How smart really get and what can I do with all this fabulous artificial intelligence that people keep talking about? The next question so, you know the way that we're building our platform is by building first and foremost value adding products. So we started with quality now editables.

We have a few things lined up. They're really excited for next year and over time. We would like really to cross reference many these data points and provide insights on top of that.

So that's all the roadmap and I would love to leave that as a surprise for the future. alright as we go along do you think that the business side is going to want to see more of this data because they're trying to align business processes with software development processes because the business is so dependent upon software these days. So will we see some different types of people starting to tap in this data for different kinds of use cases?

Um, that's According to our experience and unfortunately, that's been a bit of a reality over the last decade decade or decades really is is management trying to measure performance using you know kpis are now they're not suited to understand performance, you know for many years. We've heard people measuring engineering performance by lines of code produced or number of pull requests now created and it's such a bad metric right because incentive either the wrong behavior and it's not really great. And so that's why one of the reasons that that we brought this for the market was because we saw a change and and introduction of of research into the industry that was really helpful and human and that was accelerate the book.

We think that that brought an understanding of metrics that get at the same time be productive. For engineering teams, but also co-related with business outcomes whether those are profitability or or better Market reach and so by measuring the door metrics, we think that's a great simple way for people and Engineering teams to be better and to measure their progress while not at the same time to be intrusive or to be controlling and monitoring which is the wrong approach. So we think that if management decides to measure deployment frequency and as long as they don't over index of that Matrix and see the whole scope, we think that that by itself could be a good thing.

How mature an organization do I have to be before I get into devops intelligence a lot. Organizations are pretty far down the path others are newbies. Is there some point in the arc where they become much more capable of absorbing this kind of information.

That's an accent. Excellent question. We we've seen that there there's different concerns when you start to scale an organization when you really starting out and then just one person doing everything.

There's not gonna be a lot of of concerned for deployment frequency because if you're deploying once a year, you're not gonna be doing that for long, right? So we think that there's a threshold by which these are mandatory in before that that should be an advisory. Right and you should be measuring that to have a sense so that you scaling well and you're hiring well and you see the impacts of that hiring growth, but after some thresh will we know that that's critical, you know, as soon as you hit 50 a hundred head count in your engineering organization that's becomes really important because it's a tree right?

Have managers you have teams and so to understand and again in a culturally healthy manner. The your engineering performance is really important that that you have these these controls in place. So, you know, we think that although this is these metrics that we provide not only from the quality perspective also from engineering performance perspective.

They can be used by everyone in industry. And we do have customers from all Industries and sizes and and sophistication. We do see a real need and real concrete pain point from organizations that I have either hit hyperscale hyper growth or have either Legacy or hiring demands.

They're really really big and so those are where our Solutions are really shy You of course get to see a lot of this data and have seen a lot of patterns yourself. What's the one thing you're looking at today? That just makes you shake your head and go.

I can't believe we still doing this. Yeah, I I mentioned a number of times, you know, we've over the course of these nine years of building quality and solutions for for teams. We've always tried to be very agnostic in the way that people use the data and the insights that we provide for them to make better decision that products and so we've seen you know companies that tried to use some of that I say for example static analysis results or or test cover results for performance indicators and individual level and that for for us is definitely not the way to manage manage teams, and it's it's not sustainable and more and more the this this Industries becoming aware and adapting to in vocal to the dangers of measuring the wrong things here as we know software is not really palpable.

We cannot see like a bridge the results. Takes time to build great software is a continuous thing and therefore the metrics that really need to be. Well Chosen and well measured and continuously measured and so, you know, We literally Michael launched the product because we're first traded with people measuring the wrong things.

We saw people trying to measure and grade developers or lines of code and all these horrible metrics. I decided you know, let's try to do something. Nice.

We see this need we have customers that want to measure the right thing is let's get them what they want and that's why we brought the second product to Market and the reasoning why will we're building this platform is we think we can extend this Vision this rationale to more products right over time and build really a cohesive solution for engineering teams to understand what's going on. So, that's why All right, folks check those assumptions because odds are they're probably wrong Jamie. Thanks for being on the show.

Thank you so much Michael. Alright, that's the studio guys.