#1 – Technical Debt in the Salesforce World

In Best Practices, Change Management, Custom Development, Salesforce Administration, Tips & Tricks by Jim Lambert

Article #1 in series on Technical Debt.

Technical Debt or Tech Debt. A pay me now or pay me (a lot) later situation that the mere mention of can send shivers down the spine of IT leaders.

While not limited to any one system or technology, it is very real with Salesforce customers who are working in rapidly growing and changing environments and pushing the capabilities of their Salesforce system.

Most in the software development world are familiar with the concepts of Technical Debt.  Put simply, it reflects the implied cost of additional rework caused by implementing easier, faster, less costly “quick fix” solutions versus better approaches that can be harder, more costly, and require longer duration.  Over the longer term, the impact of Technical Debt accumulates, sometimes exponentially, as companies “pay the interest” on taking easy, short-term approaches.  These decisions that increase Technical Debt can result in systems that are:

  • Riddled with bugs or bad data
  • Unscalable and adversely impacting business continuity
  • Highly expensive in the long-run and difficult to maintain

Living with the Cost of Technical Debt

There are real business costs to these longer-term deficiencies — these can include:

  • Systems so complex that it is difficult to make even the smallest of changes to meet business needs or implement new functionality
  • Projects to improve the system become increasingly expensive and decrease stability
  • Staff risk increases where:
    • Only a few people know how to make any changes to the system
    • Team members are demotivated due to the increasing complexity and slower pace of change, and the frustration of business users they support
    • New staff are reluctant to join in fear of inheriting Byzantine systems that are difficult to maintain
  • Lack of trust in the system and data, causes the Salesforce team to be viewed as a cost center rather than as a profit-making enabler.
  • Cost to refactor and reduce technical debt can accumulate to such a level that it becomes too prohibitive without a complete “re-do” or otherwise massive initiative

As software complexity continues to rise, Technical Debt can become a major hindrance to progress.  Keep in mind that there will always be Technical Debt.  If you are using Salesforce anywhere near its capabilities, then it is likely supporting a complex business process that has urgent demands.  Decisions may be made daily on tweaking the Salesforce system to meet business needs.  Quick, short term decisions to “get the job done” tend to have long term consequences. That’s okay – the business value of speed is often the right decision, particularly in dynamic, competitive industries.  However, as the system is “accumulating interest,” one must also have a plan of action for addressing the longer-term effects.  It’s too easy to skip taking the time to understand the longer-term impact of any decision.

Technical Debt Gone Too Far

We’ve seen many examples of this with companies who have either consciously or subconsciously focused on the short term.  Some examples of high Technical Debt experienced by our customers illustrate the real cost:

  1. So many fields that making any one change required examining many hundreds of reports to see which ones would break or create data integrity issues.  This caused the customer to avoid at almost all cost any changes to the system.
  2. Decision to create their own Visualforce pages rather than use native page layouts.  When Salesforce released their newest version with additional features, they could not take advantage of any of it with their custom pages.
  3. A quick and dirty integration that got the data over, but as their business scaled, they started to run into governor limits that caused the integration to break, creating service disruptions.
  4. Making all of their changes in production, not creating a strong staging process for adequate testing before go-live.  This resulted in bugs and other similar outages that during one month affected the customer’s ability to create quotes.
  5. No documentation of any aspects of their system.  When the administrator left, they had no idea how to maintain the system and had to consider starting from scratch.  User adoption naturally began dropping and critical data was not being put into the system for reports.
  6. Hundreds of Process Builder processes existed, with many individual processes per object, causing troubleshooting and changes to be a tedious job that resulted in processes “stepping on each other.” Adopting new automation into Salesforce then became prohibitive due to the risk of adding additional issues or the length of time required to research and safely implement the now complex changes.
  7. Volume of quick-fix changes and technical debt then prevented the ability to utilize new features and enhancements available in new releases of Salesforce products.

The next article in this series on Technical Debt goes beyond the definition and illustrations to cover best practices in avoiding and managing Technical Debt. Watch for Best Practices in Managing Technical Debt next week.

 

About the author.

Bill Greenhaw

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