Enhancing Code with Continuous Feedback – Roni Dover, Digma

This is techron tv. Hi everyone. Welcome back here to techron tv.

Have another new company and a new person here on techron tv. To introduce you to, I'd like to introduce you to Roni Dover dot. Ronnie is the Chief Technology Officer for a company called dma, d I g M a.

And Ronnie, welcome to Textron tv. It's nice to have you on. Hey, Ellen, great to be here.

Thanks for inviting me. Thank you. So, Ronnie, you are the, uh, c t O for dma, but let's hear, let's hear a little bit about your journey, your life journey.

How did you come to be here today? So I'm a developer, uh, by background for more than 25 years. Um, I kind of couldn't quite pick between product management and development throughout my career, which was kind of my personal tragedy.

So whenever I was a developer, I couldn't stop thinking about the why. And whenever I was a product manager, I was kind of mourning my time away from the code. Uh, but mm-hmm.

To kind of find different, uh, ways to, to bridge the two. Um, and kind of what got me to stigma was the, the fact that I, as, as a developer and a product manager, I was kind of noticing the developers have much less feedback than product managers. And this is kind of what got me to notice a lot of things about the development process, um, and about why it's, it's really critical for developers to understand their code better.

Absolutely, absolutely. And you know what? CTOs are great for someone who, with the dilemma you have, CTOs gives you the best of both worlds a little bit.

Let's talk a little bit about d though, a little background, a little history. Let, let's hear a little bit. So DMA was founded about two years ago.

Um, and the concept was we wanted to create the first continuous feedback platform. Now, continuous feedback is, is a new type of idea within software management. And the idea is that you want, um, as much feedback as possible as a developer about your code, um, in order to prevent and uncover issues before they even occur.

Uh, so you can think about it that way, that today we're kind of at a juncture where as the phrase go goes, we have the technology. So we, we know how to collect a lot of data about the code, um, about the runtime, about how it behaves in real environments, about how it behaves on my machine. But what was frustrating me to the point where I was starting to pull out hairs and frustration was the fact that developers were using none of that.

So yes, the feedback that we know as developer is debugging, uh, and maybe running tests, but even with tests, we're using a very limited subset of the data that they produce, which is basically the pass fail. So a lot of things get, uh, kind of, uh, go, go unnoticed. Um, and I think couple that with the fact that developers are kind of, or in organizations are very forward-leaning and everybody's thinking about the roadmap and nobody's kind of listening to that feedback.

And you get a situation where we were trying to accelerate releases, but essentially to me it appeared like sometimes we were just throwing features over the fence at a higher velocity instead of really creating a learning process. And, uh, I actually found this quote recently by Kent Beck and he said, you know, optimism is an occupational hazard of programming and feedback is the treatment. And I just came by that like two weeks ago and I was, it, um, really hit the nail on the head for me because this is, I think exactly a part of the problem.

I love it. And it's exasperated by other trends, uh, that we're seeing in the industry, which is LLMs, for example. So, you know, I've just seen a study by copilot that said, developers write features 55% faster with ai.

Awesome. But then think about how much code there you have that you have even less visibility about what it does because it wasn't even written by a developer. So to me it seemed like it, it ha there has to be much more visibility for developers so that they can have confidence in their code in LLM produce code and other, uh, people's code, legacy code.

All of that needs to to, to be clear to them. And this is kind of where Dig McKay comes into the picture. So I, I would put forth the proposition, it's not just developers, but the ops people want to have confidence in that code too.

Yeah, right. There was a time, you know, the old, the old saying, right, it ran on my machine. Uh, well that's great, but it didn't run on the server and it didn't run in production and, and that's why you developers make us crazy, right?

Some ops people still have that attitude. And, and now with, with the introduction of, of, you know, generated code, machine generated code, uh, it's even more so. But you know, Ronnie, I saw an interesting stat the other day.

Something like 42% of all the code in GitHub has Gen AI fingerprints on it. So either gen AI generated the code, checked the code, helped with the code, there was something to do with AI in, in, in that code. So that means almost half of our code today right, is being touched by this.

And, and so I'm a glass, the glass is half full kind of guy. I think that's not a bad thing. And I think as AI becomes better at generating code and doing code and checking code, it'll allow us to do so much more faster.

It's gonna make developers so much more productive. I'm not one of these guys who think we're gonna put developers or testers or anyone outta business. I think it's gonna make us more productive, but we're gonna generate so much more code.

I would go one step further that developers that don't adopt gen I will fall behind. And organizations that don't use gen AI to get more team productivity will fall behind as well. But the question is how do you offset that with the right guardrails?

So, you know, throwing a gen AI at every problem will produce code, but it will eventually collapse onto itself because you won't have, uh, the right measures to understand whether the code is good, is it bad? And what happens in these kind of situations. And lack of feedback in general is something that I've experienced firsthand in my team.

I call it B d D, and I'm not talking about behavior driven design, uh, something that many developers are familiar with. It's bug driven development and just that just means that you keep having bugs in production. You keep running back to try to find a cause.

And when you talk about observability and all of these nice things, you're just saying that you're trying to troubleshoot things that have already occurred and kind of the team is running after its own tail trying to, um, to, to solve all of these issues instead of really being productive. So in order for that to work, we need to kind of break that specific equation and introduce a lot of AI generated code that's awesome into the code base, but also make sure that that code is kind of, uh, fitting the organizational way of doing thing, that it aligns with the rest of the code, that it doesn't introduce issues, that it's scalable, different things that, you know, when you enter a prompt, you're not guaranteed that the code beyond may be working something that you also need to test will deliver on. Fair.

I think that that's something that that's really, um, um, kind of made a, a lot more pronounced with, uh, gen ai. And then the other point you were making is also, I think amazing because this is where there is a lot of asymmetry between developers and the rest of the teams because, because SREs, uh, DevOps, um, it, all of these teams have amazing feedback and observability. They have dashboards and service levels and uh, SLAs and, uh, Sloss and all sorts of, um, kind of, uh, gouges and graphs that they can look at, and they're on top of it.

Where the gap begins is when you cross over to the dev team because you have all of that wealth of information and you know, I've been to many organizations where yeah, they had all of the major APMs and that's amazing. And then you ask the dev team, are you actually using that when you're developing? Not when something is wrong and you're trying to, to run after a problem Are, are you testing your code the minute after you deploy?

Do you check if your code ran and can you know if it improved things or not? Um, and, and the answer is always no, because it's complicated and it's very reactive, like who has time to chase after a dashboard and so on. And what we tried to do was to create a developer platform, um, one that is free for developers, and that is integrated into your I D E.

So it's in your field of vision. So the concept is that you can look at any function in your code that you just wrote and see, um, how does it measure up? Do you have any obvious issues or code smells or anti-patterns, query issues, security problems, different things that we can detect right away, and how does it perform in the different environments?

What did my test tell me about this new code and how it affects the system? What does production tell me about this code? So having all of that information, just one click away and having these critical insights visible and in my field of vision so I can, it's kind of like a living documentation that's bound to the code and only by so doing, we manage to actually get developers interested or, uh, in, in that information.

Because if you talk to developers in the vocabulary of SRE and DevOps about service levels and, uh, it doesn't really match up or, or it's e it's hard to very quickly map it to my code, which is what I know as a developer. Yep. You know, I, I was at a conference last week, uh, for Jfr.

Mm-hmm. And that was something that was discussed here, which is, you want to call it shifting further left, or, you know, we had GI ups where people were doing ops and Git and so forth, but now developers want tools inside of their I D E. Mm-hmm.

They want to check the security of code in the I D E. They want to see is the code working tested, whether it's generated third party additional code, you know, a APIs, whatever you're bringing in, you're introducing to the code. The, the time to see if it works or not is in the I d e, not, not at testing before deployment.

Not to say that you shouldn't test before deployment, but it's where the, the idea is where the action's taking place today. Mm-hmm. Right.

And, and so this is in line with everything else we've been hearing. So Ronnie, let's, let's talk kind of nuts and bolts with DMA then. So it's a platform that integrates into your I D E.

Mm-hmm. It's a hosted platform like SaaS or is it, how does that work? So the way it works is you install it as a plugin into your I D E.

We we're currently focused on the intelligent ecosystem, uh, but we'll expand from there. Um, and once you've installed it, it's a standalone, uh, thing. So no data leaves your premise.

You're right now running in your own id. DMA is, um, kind of completely running within your local environment. And we did that on purpose just to minimize friction and make sure that, you know, you don't need to worry about any data, uh, PI issues, you just own all of your data.

Um, so the kind of time that it takes to set up is two minutes. Uh, you basically download up again, it, uh, configures all of the components. And then the other thing is there, there are no prerequisites in terms of existing observability to the project.

Like DMA relies on OpenTelemetry, which is amazing technology behind the scenes, but it take cares takes care of all of that on its own. So you can start any project, even one that doesn't have OpenTelemetry yet. Uh, just installed stigma.

There is a nice toggle button that says Enable observability. And once you do that, it'll automatically start collecting information about your code and then doing the data science to analyze it and to, uh, give you the results, which is basically as you work, you can see what the code you're introducing, uh, how it performs, uh, uh, detect any errors, issues, um, different types of, uh, code, anti-patterns and so on. Excellent, excellent.

Ronnie, I don't know if we mentioned the website. Yeah, so we, we, our website is, uh, DMA ai and you can go there to get DMA right now. But on, uh, September 26th, uh, we have a big release where we're actually, uh, officially releasing the product and, uh, um, we're going to have a couple of, uh, great, uh, surprises as well that day.

So, uh, that's, uh, that would also be a great, uh, day to follow us. Excellent. That, that is, um, Ronnie, this is exciting.

You know, this is, again, a big, sounds like a company that's made for this new age we've been dealing with and, and the fact that use OpenTelemetry and so forth is, is fantastic. I wish you most, a lot of success with dma. Come back and keep us posted about what's happening here.

Okay. Thank you so much. All right.

Roni Dover, chief Technology Officer dma, check it out if you're, especially if you're a developer, this could be just the ticket you're looking for. We're gonna take a break on Tech Drunk tv. We'll be right back.