Technical Debt in Salesforce

on

Technical Debt and Salesforce (and why you should care about it)

For anyone hasn't already seen this video on the role of an 'expert' during meetings, I'd really recommend it to brighten your day. 


We've all been there.


When you are in the position of our 'expert' from the YouTube video, it can be really tempting to dive straight into solution mode and build something that delights your customer from scratch. 

Surely that's one of the biggest strengths of the Salesforce platform?


Think Twice, Customise Once

Now, I'm all for making customisations in Salesforce when required, but one recent customer visit prompted me to reflect more on the impact of Salesforce customisations and the concept of Technical Debt.

This customer had a team of 70 developers working on their Salesforce environment. Impressed at the amount of resource the customer was dedicating to Salesforce, I asked what the team was focused on at present. 

The response was that they were updating their historical Salesforce customisations to prepare for Lightning activation. 


What is Technical Debt?

The definition in Wikipedia defines technical debt "as a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution".

Technical Debt is essentially a way of measuring the impact of making those customisations both now and in the future.

It is really quick to make a customisation in Salesforce, but just bear in mind that all customisations have to be maintained going forward, and as Salesforce updates 3 times per year, that's 3 lots of revision/retesting for every change you make.

As one blog put it:
Eventually you reach a point where even the smallest change must be implemented with the greatest of care to avoid impacting an earlier modification. That's the point at which you lose the agility you loved so much - ZNet

3 Golden Questions to ask before starting customisation


Some customisations have a higher risk that others of becoming outdated in future. Broadly speaking, customisations made Salesforce administrative tools (new objects, new fields, new report types etc) are more likely to be maintained in future by Salesforce, whereas custom code/3rd party integrations and products and unofficial workarounds could reach end of life support during one of the maintenance updates.

So, here's a suggested list of questions to run through for each new customisation you plan to make going forward. Please let me know if you have any different checklists/questions you run through with your users.
  1. Can this be functionality be achieved out of the box without customisation?
    If not:

    is the functionality on Salesforce's roadmap?
    If not, how likely it is to become standard functionality?
  2. Can this request be delivered by a 3rd party app from the AppExchange?
    If not:

    Are there any existing apps that can deliver some/near all of this functionality today?
  3. How can this functionality be achieved with the minimum amount of technical customisation?
    Could the business process be adapted so that it aligns with standard functionality? If Yes, go back to first question and revaluate
    Who will maintain/support this customisation?
    What is the planned lifespan of this customisation (which will depend on yours answers to 1 and 2).

Summary


Customisations in Salesforce are very powerful and be delivered very quickly. 

However, each change needs to be considered in the context of the wider platform, and all new functions need to have an agreed maintenance/upgrade plan agreed.
Good technology debt is that which increases your net worth and/or helps you to generate value - Salesforce Blog

Happy customising!

Further Reading


Icon from Iconfinder, artist Webalys

Comments

Post a Comment