Search
  • KrazyTech Team

Salesforce Technical Debt: Key Findings and Actions for 2021

Creating technical debt for your Salesforce system isn’t the end of the world; it’s an unavoidable necessity. Ward Cunningham, the American computer programmer who coined the term, maybe said it best back in 1992:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”

Decades before cloud-based systems and digital transformation became the norm, Ward recognized a basic truth of development–technical debt is inevitable, but it shouldn’t be unmanageable. Just like any financial loan, it needs to be accounted for and paid off promptly.

We know technical debt isn’t a new concept, but it always deserves revisiting. That’s why on the heels of our 2020 Salesforce Talent Ecosystem Report we felt an obligation to explore technical debt in the context of evolving demands for Salesforce talent, particularly two interesting anomalies:

  • Declining demand for Salesforce Architects

  • Global demand for developers is outpacing architects.

Declining demand for Salesforce Architects: a troubling trend for Salesforce customer organizations


Our 2020 Salesforce Talent Ecosystem Report found that the YoY global demand growth for Technical Architects took a considerable hit. This may be indicative of organizations shifting away from long-term, strategic focus in favor of quick win customizations and add-ons. This can, unfortunately, result in an accumulation of unmanageable technical debt over time.

Global demand for developers is outpacing architects. How does this indicate a risk of incurring more technical debt?


While experience levels and focus areas can vary greatly, a Salesforce architect is generally a seasoned expert who defines, designs, and executes solutions on the platform (ideally from the onset of a project). Alongside developers and administrators, they help guide a company’s Salesforce vision and act as a technical advisor throughout the entire engagement. A good architect can effectively communicate and ensure consistency with a range of people, from the C-Suite down to individual contributors

One of the easiest ways to envision the architect/developer relationship is considering what it takes to build a house. Without an architect designing the blueprints and final configurations from the onset, the house being built will be riddled with issues to be dealt with at some point in the future–wasting both precious time and money.

Identifying Technical Debt in Your Own Salesforce Org

So how do you know if your company is creating or carrying too much technical debt to shoulder? 10K has partnered with hundreds of Salesforce customers from Fortune 500s to startups – their leadership sat down to explore the topic and trends further.


“Everything is technical debt”, some debt worse than others

The broad definition of technical debt is, whether code or declarative, the customizations previously made where standard functionality was not applicable or available. But it also includes functions that were built quickly and without a comprehensive understanding of the business requirements or things that were built to work one way but the business needs have evolved and maybe you’ve bolted on small tweaks over time.

A more helpful way to think about technical debt is that everything is technical debt. Some of it is low interest, such as a workflow that is doing what it should, and some would be considered high interest, like that function you’ve tweaked 12 times in the past year and is throwing errors every couple of days.

The Salesforce platform is constantly evolving with new offerings and functionalities, so your program’s customizations have a certain shelf-life before they’ll be considered stale. What works today won’t necessarily serve your organization’s needs next year, three years, etc., and that’s okay! It’s the nature of the tech-driven world we live in.


Salesforce-Specific Examples of Technical Debt

  1. Prior to the release of Sales Path, companies needed a visual way to represent an opportunity stage/process. They would have to customize a visual force component to show the progress of an opportunity. Once Salesforce released Sales Path, those visualizations then became standard and, consequently, shot up the technical debt interest rate.

  2. When we founded 10K we quickly realized the need to automate our invoice generation. We wrote an hourly function to generate invoices with some simple rules. As our contract structures evolved, additional functions were added to our once simple job. These changes became hard to maintain, so we carved out time to rewrite the job based on the then-current state of the business. Now, in 2021, we’ve seen several further iterations of functionalities the job needs to perform, so another rewrite is on our agenda for the year.

Keeping Technical Debt Manageable

“Are there any repeatable lessons for keeping technical debt manageable?”

Absolutely, and they’re fairly simple.

  1. Embrace that technical debt is inevitable and build consensus around it as a team.

  2. Audit your org and figure out what your interest rate is.

  3. Prioritize paying down your high-interest debt on a regular and consistent basis.

You need to build time into your normal operations to evaluate and pay down technical debt. Every stakeholder, both business and technical, also needs to understand the current state of technical debt interest in your org.

Time and again, our work has revealed that the best way for any organization to systematically manage its technical debt is by establishing a Salesforce Center of Excellence. We’ve written scores on the topic, including a how-to handbook, but we recommend getting familiar with the concept with this introductory blog.


Post Source Link

7 views0 comments