#2 – Best Practices in Managing Technical Debt

In Best Practices, Change Management, Custom Development, Salesforce Administration, Tips & Tricks by Andy Yang

Article #2 in series on Technical Debt.

Good Practices Make Good Systems

Not surprisingly, it takes work to manage Technical Debt, and there are multiple approaches, none of which apply to all situations.  Every Salesforce customer has different business requirements, different skill levels, different technical systems to support the business, and different levels of Technical Debt already accumulated.  In this article, we’ll touch on some best practices that may help spur improvements to your current environment and proactively minimize future Technical Debt.

Change Control Process

Most organizations starting to address technical debt try to get a handle on how changes applied to the system.  Who is making the changes?  Are there multiple stakeholders involved from different departments?  Are changes communicated before they applied?  Getting control over this process is critical.  Many companies opt for these types of process changes:

  • Identifying the number of system administrators and reducing to only what is needed and nothing more. Use delegated administration or multiple profiles for different administration tasks, when appropriate.
  • No changes are made to your production Salesforce instance without review and approval by a change control board or similar governance body.
  • Every change must be analyzed.  Some parameters might be:
    • Who is requesting the change and why?
    • How does the design meet the business need?
    • Has the design been reviewed for scalability, simplicity, and longer-term growth?
    • What system(s) and object(s) are affected by the change?
    • What is the impact on the “-ilities”  (e.g., scalability, usability, security, …)?
    • What are the risks?
    • What is the expected lifetime of the change?
    • How can the change be removed?  

Keep in mind that incorporating change control processes will likely mean saying ‘no’ to the business more often, but when done correctly will result in a much healthier environment.  Otherwise, allowing your system development to be driven 100% through short-term requirements from the business will often result in a complex system that will not serve the business well in the medium to long term.  Sometimes a system change is a bad idea.  Sometimes a better business decision is a change in the process rather than a change in the system.  That being said, the goal is to be as responsive to the business as reasonably possible.

Design Considerations

Establishing and maintaining certain design criteria can go a long way in alleviating problems later on. Common ones to consider are:

Have a Roadmap.
Proactively developing a 1-3 year plan for system evolution helps gain business buy-in to short-term approaches and priorities.

Keep it simple.
For example, creating complex automation (e.g., an approval process, process flow, etc.) that address every edge case may seem fancy, but can create a complicated system that is difficult to debug when something goes wrong.  It also becomes extremely difficult to add additional capabilities.  Keep it simple at first, depend a little more on process and training, and learn from your users. Over time you can gradually improve it, avoiding a mountain of automation that overcomplicate things from the start.  This is where a strong partnership with the business lead is key.

Avoid code where possible.
There’s a very simple hierarchy that tends to minimize technical debt:

  • Can it be done through point and click configuration?
  • Is there an AppExchange app? Often an AppExchange product represents the best practice for the function in question and gives you upside in taking advantage of the features they provide that you need as your business matures. Some may be wary of the cost of purchasing an app, but there is a significant cost to DIY, especially around maintenance.
  • Does it require code for performance or limit reasons? If you avoid code, it makes it much easier to maintain and enables you to take advantage of feature improvements in new Salesforce releases.

It’s a good idea to continuously audit your system for technical debt and to identify areas for improvement.  This takes time and skill.  You should have someone who is experienced with Salesforce, and with technical systems in general, to identify the amount of technical debt as well as the list of improvements to address it.  While not an exhaustive list you will want to look at:

  • What parts of the system are used and not used (e.g., profiles, fields, layouts, objects, apps, etc.)?
  • How much code is in the system and reasons for its use? Are there now better alternatives (e.g., AppExchange products)?
  • Quality and consistency of code, configurations, documentation, etc.
  • Processes used (end-to-end) – From requirements gathering to design to build to test and release
  • Issues experienced, such as bugs, outages, data integrity issues, speed of change, and more.
  • Consider using assessment tools, such as on the AppExchange, to help audit and evaluate your current org (Field Trip, Optimizer, etc.)

Many organizations form a governance board for reviewing changes, as well as various Centers of Excellence for analyzing and coming up with best practices and standards.

  • Make sure you have adequate skills and experience on staff to suggest, design, and review changes.
  • Design Debt is an offshoot of Technical Debt – lazy or poor design increases Technical Debt.  For instance, modularizing, streamlining, and optimizing the code is a good practice versus hard coding, which creates inflexibilities as things shift and will likely break if anything changes.

Testing and Go-Live.
All systems should be adequately tested.  This may mean the following:

  • A proper testing environment using one or multiple sandboxes for testing that mimics the production environment as best as possible, including the use of good data.
  • Not just unit testing, but real system testing that tests common scenarios, edge cases, etc.  User Acceptance Testing is critical, particularly for new features, and gives a great picture of how your go-live is going to go. 

If a new person comes on board, you don’t want them second-guessing the changes you made.  No one likes to hear that the new administrator said the system was set up horribly.  Documenting the system and the changes involved will provide any new staff member (whether you are still there or not) with the insight necessary to understand the decisions made and enable them to be successful.

Working With Business Users

Long-term benefits often lose to the urgency of short-term gains. In a competitive environment, it feels like there is no long-term if the short-term is not addressed.  It’s just the reality of IT.  No one is arguing to make a perfect system – there will always be some amount of technical debt.  But if you want the system to be responsive over time and your data to be good and trustworthy, it’s good to be smart about how you make changes.  Beware the IT trap of being a naysayer to progress, but also use the opportunity to educate and therefore collaborate with the business user.   Most of the times tweaking a field doesn’t take 5 minutes. For example, what do you do with all of the existing data in that field?  Should it be converted?  What reports are changed?  What integrations are affected?  Often when you engage deeper in the discussion, the business requester begins to understand the complexities involved.  Giving the business user a seat at the table and actively involving them in the governance process helps to create strong alignment and collaboration, and gives them an awareness that technical debt affects them greatly.

The next article in this series on Technical Debt will discuss options and methods to address existing Technical Debt, getting you back on track. Watch for Recovering from Technical Debt next week.

About the author.

Bill Greenhaw

Salesforce Principal Consultant, MondayCall
Salesforce MVP
Founder, NorCal Dreamin’ Salesforce Conference