Lorenzo Frattini, who joins to talk about Salesforce technical debt, is a London-based Salesforce CTA and the founder of Clayton, a code analysis SaaS that specializes in vulnerability scanning and code quality for Salesforce.
Main Points
- Lorenzo’s self-introduction and his play-by-play video
- What is the content of the technical debt handbook released by Clayton?
- Why is it difficult to have technical debt under full control and what shall we developers do about it?
- Number 1 cause of technical debt – Test data factory – according to the handbook
- Number 2 cause – dummy tests
- The risk factors for accumulating technical debt
Links
- Lorenzo’s Linkedin
- Lorenzo’s Twitter
- The technical debt handbook released by Clayton
- Clayton company home page
- Lorenzo’s play-by-play – Automated Code Analysis in Salesforce
Video Teaser on Salesforce Technical Debt
Outro Music
Buoy Base Galaxy – Super Mario Galaxy
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:14] Hey everybody! This is Xi Xiao. This is here another new episode of Salesforce Way podcast. Today I'm sitting with the new guest. His name is Lorenzo Frattini. Hello, Lorenzo. Hello, Xi, Lorenzo. Would you like to introduce yourself before we start? Sure, of course, with pleasure. So, I'm the founder of Clayton. We are a Salesforce-focused security scanning and code analysis tool for Salesforce. We are a small organization that is based in London. And I come from a technical background. I've been working within the Salesforce ecosystem for the past six years, I believe. I've been doing a lot of work with consulting partners. And I am a certified technical architect, so I come from that kind of angle and project complex project experience. Let's put it this way. Yeah, so I know that your company is Clinton, and you and Robert Sosman, you had a play-by-play video with Don Robbins talking about basically your tool. Yes, we were talking about the topic actually. So the the broader topic of static code analysis is something that comes up a lot. But developers, you know, they normally don't deal with the technicalities of it. It's just more something they want to use to make their job easier, and there is value to it if done if done properly. But you you don't
[01:44] typically deal with the type of Algorithms and techniques that are involved, right? This is a detail that is typically, you know, hidden from even from the view of developers, right? Yeah. So the idea with that was just to um do a session that. Was the intention was really to, you know, just tell a bit more, educate a bit more about the topic, and you know, some of the key concepts and things that people should be aware of when picking their tools, and you know, the pros and cons of like different approaches. So that was the that was the idea. Hopefully, it was enjoyable and informative. Yeah, it was definitely, yeah. And I will put the link down in our show notes for our listeners to to check. Please. Yeah, and today our topic is about technical debt. Yeah, it's a kind of broader scope. But the reason actually I want to bring you in to talk about this because in your company you generated the material. It's actually really about the technical debt. Let's look at for wisdom, your company, what you have found out about the technical debt. Am I right? Well. Yes. Well, we we published a study around this that was specifically intended for telling a bit more to Salesforce professionals. This is what we found out. This is what we learned, right? So, what we do with our solution, we basically
[03:15] help teams that work on the Salesforce platform and build apps or solution for the customers. We we help them in getting their code right, so we make sure that it doesn't contain any vulnerabilities and it's scalable and future proof. So, in in very simple terms, we help them avoid technical debt, right? So. Because we help them and we are building a technology that processes a lot of code, we can and and we detect problems and we detect when those problems are fixed. We have a fairly good idea of what are the most common problems, right? So we we scan roughly eighty five million lines of code per day. So that means that we we have a pretty A good understanding of what are the common issues and the the the things that typically developers leave behind, or maybe the mistakes they make. There might be a number of reasons, right? I I don't think this is a this has anything to do with blame. It's more about understanding what is. Typically, holding teams down, yeah, and holding teams down, and you know, creating friction and slowing down agility in the long term. So that is the kind of the rationale we had when we decided to. Kind of publish a handbook around this, so the handbooks cover some
[04:45] of the key findings, like what are the most common problems, like the top ten things we found out, and how big is technical debt? Because technical debt is something that. It can be quantified. Actually, should be quantified. Every team should, you know, have a measure that, right? Yeah. And and and we try to provide a framework to do that. So we we tell Salesforce teams, these are this is how you can measure it, and this is how you can find out how bad it is and what you should do about it, right? So there are. That that is the kind of the intention behind the the work we did is the first for us. It was a very successful experiment. A lot of people downloaded, so it means that it's certainly a topic that a lot of teams care about, which is a very good thing. Yeah, good. You know, I'm one of the people who cares about this, both from my personal experience and because I'm working in a consulting company. So I get the chance to meet a lot of customers who are using Salesforce to work. So from personal point of view, I'm a developer. I'm writing code, even when I write a personal side project. I feel that by the beginning, it's really easy to control the code quality. You easily design the solution, the software architect is easy, but along the time, even if I have only one person in the team. The code just get a bit rusted, and
[06:16] then you just get bad and bad, and then one day I really don't want to touch my code anymore. And the round actually, it's a loop. It come back again. Okay, I shut down this project, start a new one. Then the same thing happens. So that's really got me thinking. You know, got me thinking. What is this? What? Why it happened like this? Was because I'm not capable of writing good code, and not capable of control this architect, or is there something else? So I also look at look at a lot of books about this. So technical debt is definitely something I'm really interested in from my point of view, and also the customers I've seen many customers who has had the Salesforce for couple of years, the work, and then eventually they're suffering so much they have to start from the beginning again. They just toss away the existing environment and start new. And you know a funny thing is that a lot of things happen again. Just like my personal project, after two years, the oil gets kind of smelled again. So it's not really. Yeah, it's really not easy to to control this. So it's very hard. It's very hard, and it's never about you. I mean, we as developers, we we are creative individuals. We are given a problem, and we approach it in creative ways. I mean, rarely there is a right and wrong kind of a binary approach to coding, right? It's a creative exercise, and
[07:46] there are infinite variations and infinite approaches to every everything we do, right? So, um. You shouldn't blame yourself too much if you experience it. It's perfectly normal, and the the code you're writing today is it. It may not be perfect. It's definitely better than the code you used to write one year ago, and you will be surprised how better you will become over time. So, it's you shouldn't worry about what you're experiencing. You're as everyone else. Everyone goes through the same journey, and it never ends. So. That is one problem you shouldn't worry about. Thanks. You're one of the nicest guests I have. But it's true. I mean it. And I. So there is. I mean, I haven't watched. Maybe I will change my mind. Look at her. What I was trying to say is that it's okay. It's perfectly fine. And there is always the important thing is to have a an interest in getting better over time, but is is is not. It's not professional or a developer-specific type of aptitude. It's something that it's, I believe, should be done across everything we do in our life. The fact that technical depth is something worth talking about, especially in this ecosystem, is something you you mentioned yourself, right? So we are. This is an ecosystem
[09:16] that is primarily led by consulting companies. That are, of course, they are invested in happy customers. But at the end of the day, you know, we are a lot of people that are coming in solving the problem, leaving. And customers often they are not very well equipped to measure technical debt, and so what often happens is that once some solution hits requirements in an acceptable way and gets to production and. Gets across the line. That's that's fine, but complexity piles up over time. The concept of technical depth is exactly an expression of how when you take a shortcut now, you're actually. Building up a debt that you will have to pay at some point in the future. It's. I think you are starting with the right approach, right? The right mindset. You care about these things even on the low, the small scale, and that's that's exactly what I I would recommend doing. So I think you're doing the right thing. Okay, thanks. And I also read the study material your company shared. Not only it talks about the technical debt, how important it is, and it really gives a number of things related to that. So, for example, what's the top three common technical debt in
[10:46] the Salesforce works? You're talking about, for example, the test the data factory, that's ranking number one, right? So yeah, well, so let me let me just just to clarify a little bit about you know the approach we're we're taking on that. So technical depth is a broad term, basically. Is is something that is a concept that captures the entire need for reworks that you are piling up, right? So in in a sense, technical debt is the money you have to pay to get back to a healthy state in your solution code base, whatever you're building product, right? So it's a broad term. It's not just bugs in the code or like. Poor solution. That is a big part of it, but it could also be processes that you don't have. One could argue, and rightly so, that. If you are not agile enough in your deployment, yeah, it's an area of technical debt because that is something that is going down. So it's a broad term, but of course we focus on the code-related part of technical debt. So there is an element that is very easy for us to quantify because we can look at all your code and metadata.
[12:08] That define your org, and cross-check how many best practices you're violating, how many security vulnerabilities you're you have in your code, and we can estimate. Okay, how long will will it take to fix those? So in that sense, we can translate an analysis into a number that could be hours. Of fixes that we predict, that we we estimate, or or money, of course. So typically, you will hear about the measurement of technical debt is in money because that's that's basically what debt is, right? So in our handbook, what we did was we looked at everything that we learned since we started doing what we do, and we looked at what are the the top problems that we see more often. Right, and that's that's the ranking you refer to, and I don't remember. I I can read it for you. So the the ranking first is the test the data factory. Right. Okay. That's an interesting one. So we are basically saying that that is the number one cause of of yes technical debt. That I I don't think if that is the right way of thinking about it. But it's definitely a problem that is very common. And now I'll tell you why this is a problem. You you are basically in Salesforce. You are building your applications around objects. And
[13:39] whenever you are building logic, you need to test this logic. There is actually required by Salesforce itself that you have a certain degree of test coverage, which means that you need to have a certain number of test methods, right? The fact that you are not using a data factory or test builder means that in your test you have something like account A equals new account, insert account, and then your test. Why that is a problem? That is a problem because multiply these by hundreds or thousands of tests. The day your admin creates a validation rule on your account. You have suddenly hundreds of hours of fixes just because you created your objects directly in the test method. I understand it's a very technical statement, and it's not for everyone to you know understand the the nuances of this. It's not in itself a big deal, but it's a tiny thing that can have a major impact. Yeah, and we see that very very often. I I think it's something like almost sixty percent, if I remember correctly. I mean, six orgs out of ten have this hundred percent. Okay, because I I remember I read documentation from Salesforce. The test data factory is really a best practice. It was recommended, and also from the coding point of view, do not repeat yourself
[15:09] is also principle, right? When you whatever you do, whether it's a production code or the unit test. You repeat to create the same object records. Then you should put it in a centralized place. So the idea is simple, right? You have a single place data factory. There is a more modern approach I would suggest to look into, which is called the data builders. Data builders. Okay. Basically, the idea is that you have a It's different style to do the same thing. You have a central class in your code whose purpose is to just to create instances, valid instances of your objects, ready to be inserted in the database. So give me a test account. Right, and you have a single place in your code, and all your tests will use that method, that factory or that data builder to have a valid test account to be inserted in the database. So whenever you change the validation rules around the account, there is one single line of code that you have to add. Even if your tests are Um, hundred thousand. Yeah. Whereas, if you don't do this, you every single test that uses an account is a test that is going to break, and is a test that you will have to fix. And every fix will slow your agility down. So, like a feature that will take one day becomes a feature that takes. Fifteen days. Yeah.
[16:45] Hey, thanks for listening to the show, SalesforceWay podcast. It's all the time looking for both guests. And topics. If you have guest recommendation or any topics you'd like to listen to, don't hesitate to let me know. My Twitter, LinkedIn, and email information is at the end of the show notes of each episode. You can also find it on the SalesforceWay.com website. I really, really, really need help from you on this matter because only you, my lovely listeners, know what yourself want. So, please help me invite great guests to talk on great topics, so that we spread great knowledge. Now, let's get back to the show. I
[17:41] think it's easier for developers to understand if you have code. Sometimes you have some experience. You definitely have suffered from this point. Oh yeah, yeah. I mean, if you have looked into someone else's code, I think that is a very good thing about consultancy. Actually, when you when you when you have to look into someone else's code, and maybe you're frustrated about it. That makes you become better, and to me, I think you want to leave the world a better place. Like, and I feel like you you want to do it as well as a developer. You want to kind of fix things and leave them in a in a nicer state. Indeed, indeed. And the other point ranking in the list is the dummy unit tests. I'm not really sure what that is. Could you open it up for us? Well, okay, that's that's that's another one. I mean, as a developer, you need to make sure that everything you write needs to have a certain amount of test coverage. If you don't have enough coverage, you cannot deploy. So everyone is like super crazy about coverage, right? The problem is that sometimes people just, you know, maybe they they have to cut corners or ship to production quickly, and what they do is they create tests that are not actually Checking anything, they're just they just exist to traverse the code, just to go to to boost the coverage up, but they don't actually. Assert that your logic behaves in a certain way. There's no validation,
[19:11] basically. There's no validation. So you typically you open an org and you find like a lot of like methods that exist for no reasons, just to to be very long and very silly, like I plus plus repeated a hundred of times, and then you have a test that just run that. And that's a logic that that's that's a piece of logic that is absolutely not relevant. It's not used anywhere. It's just there for the sake of boosting coverage up. Yeah, this is truly insane. A little bit to me. To be honest with you, it is. It is. It's. It's a very, it's a very stupid way to solve this problem because again, this is like massive or technical depth. You are solving a problem like now and creating a much. Bigger problem that someone in the future will have to deal with. Yeah, I understand. You mentioned it as well. Sometimes people have the pressure, right? You need to deploy your code by tomorrow, so there's a hard deadline there. So that's the reason maybe you do this dummy unit test without the asserts. And also recently, I also chatted with one of my colleagues. He really did this I plus plus like hundred times. Just to increase the the coverage rate to seventy five percent, then he can deploy the code. The reason was that because we're consulting, the previous
[20:41] coder doesn't do a good job with the code coverage. He doesn't want to cover the ass, you know. Those things are are done by somebody else. He doesn't have time or he doesn't want to. So he created those side plus plus lines. To me, this is like just ridiculous. But I accept that. I mean, it happens in the real life. Yeah, I mean people pay by the by the hour. What can possibly? Yeah, indeed, that's the consulting business. That's the brutal truth. To be honest, I think there are very good. Consulting companies that try to to do things well. So we work, for example, with a lot of a lot of our customers are consulting companies that they come to us and say, "Hey, can we use your technology to make sure that everything we do across all our teams is always top notch?" Can you guys help us to achieve that? And what we do is we monitor everything they do, and and and block the bad stuff, so that that never gets shipped to customers. So I think that there are a lot of good. Companies like there that try to you know move away from these like old ways of doing things and err deeply about long term success of their customers. I believe we are at the point where in the ecosystem where it's mature enough. Like people have done this type of things in the past. But there is now a very good place for people that want to be different and do things properly and care deeply about quality
[22:12] and want to be that kind of a unique selling point of what makes them different. Okay, and of course, in the documentation, there are some other technical debts in the code you mentioned. Unbounded cycle, and you mentioned the DML in loop. Just due to the the time limitation, we won't really go into those details. But our listeners go to check the documentation. I mean, really, there are good insights over there. I think one more interesting thing I want to mention here is that the document mentioned about the risk factors. Like in what scenario, in what situation, the tech death will increase faster or slower? Those like a dimensions. That's a really good insights. As a technical leader or as a business leader, you need to understand where you are and managing risk. You should be able to gauge where you are in terms of risks. So, I mean, there are some obvious things that raise the risk. For example, if you have a high turnover. If you're like companies that have a very high turnover, developers change very quickly. Of course, that is a very very high that raises the risk, right? For the reasons you just mentioned, right? Yeah, yeah. Comes in, does deployment. That's something that be quick and dirty, but hey, I'm
[23:42] I'm not around tomorrow, so someone else will, right? So that's that's a risk factor, and there is also the cost of having developers near you. Is likely to be high, right? So there's a natural tendency to offshore a lot. The risk when you offshore is that the teams become distributed. They work on different time zones, and there's there is an introduced complexity around the the governance, right? The team writes the code, but when the code is ready to be reviewed, the the the business is going to sleep, or maybe the technical architect will like look at it tomorrow. There is a There is a barrier, and that raises the risk as well, right? So if your team is large, or has a high turnover, is geographically distributed, all these reasons should, you know, a good a good technical architect, a good a good business leader should like recognize that there is a higher risk, and that, and therefore technical debt is likely to be growing faster. Cool. Thanks, Lorenzo. I think we had a great chat about the technical debt. We started with single individual developer. I had the puzzle, and he told me, "Don't worry, everybody has the same problem." And then we talk about the top three common technical debts, and I really enjoyed that when I read in the documentation. And then also the risk factors, which is more like a more higher level for the technical lead and for the business owner to really understand.
[25:13] What's your current situation? You you need to understand where you are, right? You don't want accumulate more more debt in the future. So I think that's a really good conversation. And again, I recommend our listeners to check the documentation we will share in our show notes. Thank you, Lorenzo, and and for your company Clendo. So before we close the session, do you still have something else you still want to add? And I would be very happy if any of the listeners is interested in what we're doing and want to connect with me either on Twitter or LinkedIn. Read the handbook. Tell me what you think about it, and what type of information you would like to be included in the next edition. Right? We would like this to be something that everyone in the Salesforce community finds valuable. Right. So thank you for having me. It was a pleasure to to talk to you today, and I hope we will have another chat sometime soon. Yeah. Thanks, Lorenzo. It was great to have you on the show. I will put your LinkedIn information, your Twitter information, maybe your client and company information in the show notes as well. Yes. Okay. Thank you. Thank you. See you next time. Bye.
[26:56] Ah.
