First a bit about me, my name is Bari. I'm a software engineer here from Brazil. I have been working at the Brazil's Office of Cadence Design Systems for almost five years now.And I've been working during this time in the development of Jasper EPPS, our RTL form a verification tool. I've also been engaged in initiatives for improved code quality and to empower women in tech and outside of work. I'm also passionate about creating art with code and about cats because to not to love cats. OK. So first a bit of context about why did we want to migrate lines of Java in the first place? We had a big code base with code in Java and C++ specifically with most of the code in C++ and some code in Java connected with Java native interface. And our goal that we achieved was to get rid of Java and JNR nine and have only C++ we wanted to do it because having both languages made something hard, something harder for us. And some of the examples of when it makes things harder, are harder to set up our tool in Java, we need to set the hip memory size and defining this amount was not always straightforward.

It would also be hard to optimize the code then needing to deal with the infrastructure in Java and C++ and the connection between that would prevent us to do some rich factories and some performance improvements. And it also made the code harder to maintain overall it. So we needed developers to be able to program in both Java and C plus. We also needed our tools such as indexers, linters, and sanitizers. We would either have them have to maintain them for both languages or not have all of the code covered. So it was clear that it was preferable to have the code in C++ only, but we still have hundreds of thousands of Java lines and we couldn't migrate then all at once, we cannot stop adding features and fixing bugs to do this code reflectors. So it was a long journey, it takes time, this took us a few years with lots of developers being engaged in that but slowly but continuously, we did reach it our goal and that's what I want to talk about. OK. So one first thing I want to mention in terms of learning through this project is the importance of tracking the progress. Anything that you are not monitoring can easily get out of control. And we have caught one example of that at the beginning of the project. Actually, some years before this project, there was already another initiative to migrate lines of code that had a significant progress but left one specific component in Java. And over time, the two have progressed features were added and the amount of linings have grow again.

And at the beginning of this specific project, when we created a tracker to understand our progress and look into the past as well, we were surprised to see that we were almost at the same amount of gel lines before doing any migration and obviously tracking was also really important during our project to understand our progress um in which space we could move so we could adjust the amount of resources or our intermediate goals.

Another thing I want to mention is that this type of project is a good opportunity to leverage the abilities from people from different level of experience. Since we needed time to do the migration for a lot of time, we needed the component to work with part of the code in C++ and part of the code in Java. So we could do the migration progressively and we needed senior developers to build this infrastructure to allow the migration. Once the infrastructure was done, we could progress with the migration, which is easy. So we did have um people from all different levels of experience, experience during the migration.

But we realized that it was really interesting for beginners because they had the opportunity to talk and have the help of the senior people on how to migrate and also doing code reveals and that could really improve the the ramp up of new hires because they were able to see the code and understand the structure of our code through the migration.

And another thing I want to mention in terms of learning is that there are also opportunities during the process. The the reaching the final goal was a really important mark for us, but we did have benefits during the whole process. And it was especially a good opportunity to clean up our code. We were able to find points where we could improve the, we can improve the code in the future, also weird things and possible bugs. But also we had the opportunity to review the features. We were migrating and understand if they were still being used if they were still needed. And for some features, we decided that we could deprecate them instead of migrating. So it was a further place to clean up the cold. OK. So to conclude, I want to highlight the importance of code refactoring of initiatives such as this in our specific cases, there were also ben direct benefits for the customers. But I often for code refactoring, that's not the case, but there is always the indirect benefit for customers when we make the code easier to maintain. So we can have less bugs and have faster response times. And another thing that I think it's important to mention is that this project is lot of time, they look really big and it's hard to see the end and it can be demotivating. But I hope our experience can show that it's possible to finish.

It's possible to reach the end. But even when we are steering the middle, even when we're still progressing weak, you can still uh have lots of benefits and lots of learning and in other opportunities in the middle of the project as well. Ok. Um That's it. Um I hope our, our experience can inspire you to work in on the opportunities of code develop of code improvement, whatever makes sense in your teams and thank you so much, you can reach me on my Leine.