Salesforce Technical Debt

Technical debt is incurred when a development team delivers a business feature that is incomplete or is not a solid foundation for future enhancements i.e. future development capacity is being committed to deliver a feature today. If technical debt is not addressed, and instead additional features are built on top of the incomplete work, over time it can become more and more challenging to deliver business value. To learn more about Capgemini and Salesforce, go to https://www.capgemini.com/partner/salesforce.

Matt Prorok: [email protected] | https://www.dhirubhai.net/in/matthew-prorok-6752371a/

Erik Ivarsson: [email protected] | https://www.dhirubhai.net/in/erik-ivarsson-43066261/

Andy Forbes: [email protected] | https://www.dhirubhai.net/in/andyforbes/

Podcast: https://soundcloud.com/capgemini/salesforce-technical-debt

Discuss: https://trailblazer.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000LoWn

This transcript has been edited for brevity and clarity.

Andy: Welcome to the Capgemini Salesforce podcast series. This is Andy Forbes with Capgemini AmErika and I'm talking to Erik Iverson, a Managing Solution Architect with Capgemini Sweden, and Matt Prorok, a Field Service Lightning Solution Architect with Capgemini AmErika.

Andy: Today we're going talk about technical debt. Matt, let's start with you. What is Salesforce technical debt?

Matt: I think about technical debt within the context of the information that was known at the time. There was an action taken that resulted in some aspect of the technical implementation potentially being done in a sub-optimal way. Let me give examples of what I would and would not consider to be technical debt. First, technical debt. I'm on a project and I have a requirement for a custom field. I don't spend the time needed to investigate existing fields and miss that there is a field that I could (re)use. I would consider this to be technical debt because the way that it should have been implemented was to use the existing custom field rather than creating a new one. At some point in the future, that likely will need to be fixed. What is not technical debt? I make a decision to go with an AppExchange application or do significant customization in Apex code for a particular feature. Then, two years later, Salesforce includes that as an out of the box capability of the platform. I would not consider this to be technical debt because it was a good decision made at the time, and there is always ongoing work that needs to be done to support any application.

Andy: Erik, Matt talked about what technical debt is; can you talk a little bit about how it happens?

Erik: My point of view is it's divided in two different areas when it comes to the Salesforce platform. One of the main things I believe it is related to is unknowing. Basically, unknown-ness of the platform capabilities. Creating unnecessary fields or even setting up custom objects when standard ones can be utilized. Another thing I think is technical debt is inconsistency in design patterns and patterns in general, as well as inconsistency in business processes. So basically not having a redline to address requirements. For example, a project might utilize apex triggers for some parts of the process of automation, and in other parts utilize process builders or flows. So mixing different patterns. And perhaps the most important thing that I see as technical debt is when projects continue to build on top a poor really design foundation. Basically, constructing on top of technical debt without fixing it so you are just adding on to the pile.

Matt: I have a question for you, Erik. I'm curious how you manage that, because it seems to me that in a lot of circumstances you could end up in a situation where the thinking is "Well, I'll just make a minor modification on top of the existing technical debt since it doesn't make sense to completely refactor the component for something small." Then, several years later, you've done a bunch of minor things. At that point, you really should replace the whole functionality. How do you manage making the decision of what is and isn't okay to build on top of existing technical debt versus taking the time to refactor the debt?

Erik: I think that's a really good question. A lot of companies struggle with this as well. I think it comes down to a willingness to change even the things that are working. As long as you identify it and you decide that this minor change on it's own, it's not a problem. But you also have to think about the long term and that there is time to actually refactor this code before adding to it. I think this is the key.

Andy: It's interesting to listen to the two of you because you are more hands on technical than I am. When someone says to me “How is technical debt created?” my answer is, well, the business needs something quickly enough that I don't have time to do it in a technically correct fashion, but rather I need to do it in an expedient fashion. So debt is created because I'm addressing stated needs from the business rather than anything technical.

Erik: Yes, exactly.

Andy: We've talked about what technical debt is. We've talked about how it's created. How do we avoid creating it?

Matt: I'll give a couple examples of things I always make sure I do. The first is on the Salesforce core capability side. Every time there's a release, I will peruse the release notes. There are also webinars that Salesforce does covering the various functions and clouds. I listen to the ones that are applicable to the work I do, which is Service Cloud, Communities and the core platform. This way I always have the latest toolkit of capabilities and know the latest and greatest ways to implement features. This becomes more and more important as you gain more experience, because when you first learn Salesforce, you're going to learn the latest capabilities. As your career progresses, however, you need to spend the effort to proactively gain new knowledge rather than just relying on what you've always done. The second thing that I do on projects I work on is I make sure I'm reviewing the technical components that we are building and our design with the Salesforce CoE or Solution Architect. I go through the stories, I explain what we built, and then I make sure that I'm asking questions about the areas where we implemented something and we want to make sure that's the right way to do it for this project / customer.

Erik: Matt had very good points. I mean, it starts from the beginning, right? Strong patterns, clear design principles, communication between the team members and cross teams to build the strong foundation for the future. Doing this in the beginning takes time and an investment. If you're a project manager, if you're an architect, or if you're a developer, you have different stakes and different responsibilities.

Andy: When there is a technical debt, how do you go about remediating it?

Erik: It's about investment. It's about taking the time to invest in improvements when things are working. Allowing the team to make those changes and really invest those changes is key. Its important to communicate the business value of remediating the technical debt, because from a business value short term it might not appear to provide any value. You are doing the same thing with the same response times but the maintainability and stability of the system is decreasing.

Matt: I agree with what Erik just said. I think you need to have some level of ongoing technical debt remediation baked into the ongoing support schedule. What I have seen be successful is a dedicated percentage of sprint capacity set aside for the ongoing maintenance activities. It has to be part of the ongoing maintenance and not relegated to "second class citizen" status that is only done whenever there isn't a backlog of high priority enhancements. If you're serious about having a Salesforce instance that is maintainable and scalable, you have to dedicate the resources to do that.

Andy: It's interesting to hear you talk about tackling technical debt in an incremental fashion. I'm not saying I disagree, but I will say that I used to work for a firm that about every five years would stand up a plain vanilla Salesforce org, preserve what they wanted from the existing org, leave everything else behind, and then move everybody over to the new org. Rather than slowing down their delivery of features to the business, it took about five years for the roosters to come home to roost of not addressing technical debt in an ongoing fashion. They were willing to pay that price. For four and a half of those years, they could be hyper responsive to the business and then for half a year, they would start the cycle over again. I think there are a lot of different ways and timelines to use to address technical debt. All of this said, in this whole conversation we've been talking about technical debt like its something bad that you shouldn't create. I don't think any of us think that's actually the case. Matt, what are your thoughts on when it's appropriate to create technical debt? When do you make the decision on a project that you're going to go ahead and take on some debt?

Matt: There are a lot of considerations that go into this. Schedules, resources, money, and people are not fungible. Sometimes the right decision is to build something that will need to be remediated at some future point in time. I look at information on two dimensions before I would make a decision to create technical debt. The first is I would confirm that functionality that I was building the technical debt for was truly critical and I have exhausted any other options for implementation. Then I want to understand and get agreement from the stakeholders on the future path for resolving the debt being created.

Erik: Each team needs to really define their capability and mindset around technical debt, because what's not even considered technical adept for one project may be a huge technical debt to another.

Andy: My opinion is that this is a business decision and that the project manager needs to make sure that the product owner and the business understands and participates in the conversation around the time to deliver, resources required, and technical debt being created. I think one of the challenges that we get into on our Salesforce projects is we sometimes view the technical debt conversation as internal to our project and to our team when the reality is it is not or, at least, shouldn't be. The three of us have had conversations about DevOps. I view DevOps as an ideal way to address the issue of technical debt because the whole point of DevOps is to break down silos, is to pull everybody together, and is to make sure that we're all pushing the wagon in the same direction. I think DevOps makes it easier for the product owner and the business team to understand all of the levers they can move in order to get what they want, when they want to get it.

Matt: That's a good point. I'm curious about something you said. So was the five year increments of taking the Salesforce instance and creating a new one a planned activity?

Andy: It was a conscious decision in order to address the business needs as quickly as possible. There was a significant willingness to favor expediency over longer term technical stability. The reality is that when you've got billions of dollars a year of sales running through Salesforce, getting a feature into production even two weeks earlier is material. Either you have the team needed in order to do that and not create technical debt or you simply accumulate the debt. There's a reason that it's called technical debt. Debt isn't a bad thing. You borrow money to buy a car. You borrow money to buy a house. You borrow against future ability to deliver to get something delivered today. And the simple decision was made that rather than pay it off incrementally, that we would just go ahead and let the debt build until it was towering over that org. Based on a strategy that it was simply cheaper to stand up a new vanilla org, grab what we still wanted from the old org, and start over than to fix an org peppered with technical debt.

Matt: I can see how that would be really helpful in terms of focusing the minds on every five years taking stock of not just "what's the functionality that we've always had" and keeping that but also identifying the most important capabilities as well as features no longer being used.

Andy: It also made it very easy to look at all the new features that Salesforce had rolled out over the five years. That's fifteen releases. All three of us, I guarantee, have been on projects where we've gotten a user story, we've gone off and built something, and then within a release or two Salesforce came out with essentially the same feature. Earlier in this conversation Matt said this can't be viewed as technical debt. Well, maybe you can't. But I promise you when something that you put together is overrun by a Salesforce feature that's broader and that does more and the client can't have it until we first unwind what we did - the client will think this is technical debt.

Matt: From that perspective, anytime there's a new Salesforce release you need to do nothing to create the perception of technical debt. That just speaks to the importance of keeping up with the latest releases as well as the Salesforce product.

Andy: We all work for Capgemini, a Salesforce Global Strategic Partner, which means we have a pretty good view into what Salesforce is planning on doing. I think that's a big piece of the value we provide to our clients. However, I believe I'm digressing a little bit from the point of this podcast, which is technical debt. Anything you would like to share before we wrap this up?

Erik: Just to note the value of learning from technical debt.

Matt: I think that makes sense. We should always be learning from what we do so we can do it better in the future.

Andy: Matt, Erik, thank you for your time today.

Andy: You've been listening to the Capgemini Salesforce Force podcast series. To learn more about Capgemini and Salesforce, go to https://www.capgemini.com/partner/salesforce.