Blog

Introduction : Tech Debt

Technical debt (Tech debt) accumulates with every new feature delivered across the modern enterprise. Salesforce orgs are no exception, with years of ongoing development often leaving behind legacy Apex triggers, hard-coded Visualforce pages, and outdated Lightning components. Individually, each item may not impede agility. But in aggregate, these tangled, laborious-to-maintain artifacts comprise what’s referred to as “technical debt” – infrastructure or code requiring refactoring.

Much like financial debt though, there comes a point where technical obligations prevent innovation velocity or introduce risk. For Salesforce admins/developers overseeing expanding, highly-customized deployments, actively managing tech debt before it grows unruly is critical.

In this post, I’ll provide guidance on orchestrating large-scale refactoring initiatives spanning legacy Apex, Visualforce, and Lightning UI components. I’ll clarify best practices for structuring such projects, quantifying scope, assembling skilled resources, and establishing governance plans. The goal is equipping Salesforce leaders to tackle their org’s tech debt beast head-on and accelerate future feature delivery.

Defining The Tech Debt Challenge

First, what constitutes problematic technical debt within Salesforce? Here are some common red flags:

Hard-Coded Elements

• Apex triggers with hard-coded logic and IDs rather than modular code
• Visualforce pages directly accessing fields and records rather than controller variables
• Lightning components with fixed field references versus dynamic bindings

Duplicated Work

• Multiple Apex classes and triggers containing copied logic
• Identical Visualforce pages and Lightning components retrieving the same data
• Repeated JavaScript business logic across Lightning containers

Deprecated Techniques

• Legacy Apex syntax using insert and update rather than compiler enforced patterns
• Reliance on dated Visualforce <apex:*> tags rather than modern <lightning:*> markup
• Use of retired Lightning base components rather than current variants

Suboptimal Queries

• Bulk synchronous SOQL queries and inefficient traversing of query results
• Excessive QueryLocator iterators hindering Visualforce view state
• Lightning controllers lacking server-side action choreography and caching

The above signify opportunities for improvement – whether updating standards, removing redundancies, or optimizing performance. Much has simply accumulated as releases deliver new frameworks and paradigms.

Risks of Unmanaged Tech Debt

What are the actual risks of leaving the above unaddressed though? Consider a few:

Slowing Velocity – As complexity grows, delivering new features requires more analysis and testing effort. Even small changes can regress functionality. Iteration times slow to a crawl.

Increasing Defects – Intertwined logic and duplication eventually lead to bug-riddled experiences. Light updates introduce facility-spanning failures.

Limiting Scalability – As data volumes and user loads increase, poorly optimized code hits governor limits leading to utilization caps.

Hindering Collaboration – Disorganized projects with ad hoc standards frustrate new developer onboarding. Tribal knowledge reigns over shared best practices.

Impacting Audits – External reviews highlight disorganized logic flow, security flaws, and other issues requiring explanation.

Straitjacketing Innovation – Technical constraints prevent adopting modern frameworks and patterns pivotal to future initiatives.

Much like accrued financial obligations then, technical debt left unaddressed restricts enterprise agility and heightens risks – not ideal in fast-moving industries.

Plotting The Refactoring Journey

Given the arguments above, periodically reconciling technical balances sheet through structured refactoring initiatives just makes sense. But how exactly should administrators approach orchestrating such large-scale initiatives spanning legacy Apex, Visualforce, and Lightning UI?

Let’s explore a proven methodology.

Phase 1: Quantify Scope

First, quantity the breadth of technical debt to reconcile. Salesforce provides native tooling here including:

• Lightning Usage App – Surfaces legacy Apex, lightning components and Visualforce dependencies to modernize.
• Duplicate Rules Engine – Highlights identical components to consolidate.
• Shield Platform – Identifies vulnerable code patterns to harden.

Analyze results using built-in coverage percentages and downloadable CSV reports. Rope in development leads to confirm conclusions and clarify relative remediation effort.

Assign overall complexity scores accounting for redundancy, security, performance, and other factors. Stack rank debt by descoping low value clutter versus mission critical enhancements.

Establish initial milestone targets across the overall portfolio. The goal isn’t removing 100% of debt immediately, but identifying what delivers the most impact if addressed.

Let me expand a bit more on technical debt management specifically for Lightning web components (LWC) and the legacy Aura framework.

LWC and Aura Tech Debt Challenges

As orgs adopt the modern LWC model, they often leave behind complex Aura components with duplication and dependency risks. Strategies to reconcile this include:

• Incremental Reengineering: Migrate the highest value Aura components first. This minimizes disruption while still removing critical debt.
• Strategic Breakouts: For complex components, break into smaller LWC elements focused on specific functions. This simplifies maintaining and testing.
• Component Libraries: Establish shared open source LWC libraries to prevent duplicate UI development. Promotes reuse.

However, LWCs also introduce updated best practices around:

• Modular Design: Separate display, logic, and data layers. Contains complexity.
• Standards Adoption: Follow naming, security, accessibility principles early, not after-the-fact.
• Dependency Management: Carefully track third party module usage across components to prevent conflicts.

Phase 2: Staff The Initiative

With targets set, assemble technical forces. This requires coordinating across enterprise IT given likely project intersections. Identify both the dedicated modernization team supplemented by shared architecture and infrastructure groups.

Consider required skills and tooling access like:

• Lead Architects – For designing consolidated solutions
• Senior Developers – To productionize patterns rapidly
• Code Reviewers – To validate consistency and quality
• Release Managers – To shepherd rollout and monitoring
• Org/Metadata Access – To deploy and patch components

Ideally, leverage resources already accustomed to the legacy landscape versus fully outside parties. This accelerates initial analysis and provides invaluable historical context.

Allocate budgets for any additional contractor or tool assistance as needed over the projected timeline. Unlike routine agile development, these projects can’t easily pivot every sprint. Carefully evaluate Scope 1 conclusions before major investment occurs.

Phase 3: Attack Technical Debt

Now the real work begins by diving hands-on into remediation. But rather than permitting entirely ad hoc efforts, establish centrally visible governance plans including:

• Style Guides – Documenting code patterns, naming conventions, and modular architecture standards
• Quality Gates – Code review and static analysis checkpoints prior to final acceptance
• Monitoring Thresholds – CPU timeouts, heap utilization, and other metrics to track post-deployment

Shepherd your “technical debt attack squad” through iterating in manageable batches. For example:

Week 1: Consolidate Common Apex Utilities
Week 2: Hardened All Exposed Visualforce Interfaces
Week 3: Migrated Legacy Lightning Components to Base Variants

Concurrently run informal Death Star Design sessions to whiteboard future capabilities freed by addressing current constraints. This incentivizes teams by connecting efforts to strategic goals.

Adhere to the famous Scotty rule from Star Trek for setting expectations – target triple the interval you actually expect any effort to require. This accounts for inevitable discoveries mid-stream.

Phase 4: Continuously Improve

Finally, keep the momentum going by scheduling follow-on refactoring initiatives before dust settles from the first. Require developers to allocate 20% of cycles towards territorial code improvement in light of lessons learned. Modify intake processes from project ideas to funded efforts to consider technical debt consequences.

Institute asynchronous online “pay-it-forward” exchanges for people to share optimization tricks that helped their teams. Consider running informal developer conferences to demonstrate successful modernization patterns.

Soon architecting for low-debt, high-velocity innovation just becomes muscle memory. Teams inherently start removing impediments allowing more creative feature ideas to flourish.

The Intangible Returns

As highlighted earlier, reconciling technical debt – while sometimes less glamorous than customer-facing capabilities – provides immense enterprise value. Beyond hard numbers though, here are some personal takeaways from legacy modernization pushes I’ve participated in over the years:

Developer Satisfaction

Watching teams rediscover joy in sustainably building well-crafted, intelligently-designed systems again is hugely gratifying. There’s an energy and momentum that manifests when technical obstacles disappear.

Customer Trust

Rising reliability, performance, and scalability indicators rebuild customer confidence in the long-term partnership after periods of rocky UX. They sense future-aligned investment rather detracting attention.

Agility Unlocks

Possibly most satisfying is watching enterprise architects ideate grander visions that existing constraints once halted. Burdens lifted, the art of the possible feels limitless again.

So don’t postpone that debt conversation – incredible returns await those courageous enough to confront the beast!

Conclusion

Managing technical debt is a crucial discipline that, while less glamorous than feature building, allows organizations to sustain velocity over the long-term. As years of ongoing Salesforce customization accrues, legacy artifacts like tangled Apex triggers, overloaded Visualforce pages, and outdated Lightning components put innovation capacity at risk.

To tame this beast, administrators should spearhead periodic reconciliation campaigns by quantifying scope, marshalling skilled resources, and establishing governed rollouts. The goal is methodically establishing modular frameworks to increase developer joy, optimize performance, and unlock strategic platform capabilities over time.

Of course, no single initiative will eliminate all debt given constant change. But by institutionalizing continuous improvement sprints, conducting regular complexity audits, and investing in tool-assisted rearchitecting, Salesforce leaders can align prioritization to prevent crippling deficits.

Focus on systematically nurturing low-debt, high-agility ecosystems amidst the daily feature churn. Both customer and employee delight depend on it!

Have pending technical debt challenges or modernization stories to share? Sound off below!