Get your FREE 30-day trial.
Start by selecting a product:
Several years ago, I found myself owning one of those classic unpopular business systems. The (fairly substantial) team delivered one or two production releases each year, with a backlog of ageing change requests several releases deep, and the business users were infuriated by the minimum 14-month lead time on changes.
When I dug into the underlying reasons, there were some typical symptoms: experienced analysts described the system as a 'big ball of mud', new developers complained about spaghetti code, every change broke something unexpected, and each release was coaxed through testing with last minute duct-tape-and-bailing-wire fixes. The scared team had adopted a terrified ‘don't change anything unless we absolutely have to’ approach.
In other words: considerable energy was put into the system, but sucked into a black hole of technical debt.
Technical debt is a phrase that's chucked about a lot. Simply put, it is the ongoing cost of expedient decisions made when implementing code. It's all those shortcuts or workarounds in technical decisions that give short-term benefit in earlier software release and faster time-to-market.
Used carefully, a little technical debt is not a bad thing – it speeds development towards a short-term goal, and sometimes that deadline is the most important thing. The key, as with most forms of debt, is to pay it back promptly, before managing the interest brings you to bankruptcy.
The best platform in the world (that’s Salesforce FYI) can’t shield users from the consequences of the design choices they make when configuring and customising.
There’s a lot customers don’t need to worry about, and customers who rolled out Sales Cloud 10 years ago are still running healthily, on the latest browsers, with mobile access and Einstein intelligence, with no project investment.
So in the context of Salesforce, technical debt will typically mean any of these things:
With all this in mind, how do you go about avoiding excessive debt? I focus on five key steps.
Martin Fowler usefully categorised technical debt into four quadrants, tracking along spectrums from reckless to prudent and deliberate to inadvertent:
Design choices at the ‘prudent’ end of the scale are examples of the ‘not all debt is bad’ discussion – this is the zone associated with hitting milestones, shipping code, getting early learning, and proving value.
Prudent debt is the corollary of the agile principle that ‘perfect is the enemy of done’. Prudent debt can be deliberate: we know we're going to have to fix this later. It can be inadvertent: the world has changed since we made that choice. Either way, it’s unavoidable – the objective is to minimise reckless debt and properly manage prudent debt.
This starts with having the discipline to be aware of the design choices you’re making, and to track the debt as you become aware of it. The steps in your approach need to include:
All of the worst business software you have used was built by a contract developer working from a 160-page design document that was written by a Solution Architect from 90 pages of business requirements that were passed to her by a business analyst who was hired by the business for this project and spent three afternoons with the one guy in accounting who happened to be available that week. Put simply: the single largest cause of inadvertent technical debt is the delivery team not truly understanding the business need.
There are two high-impact roles absolutely central to avoiding this problem and successfully delivering a high quality solution that meets the business need with minimal debt. You may have different labels for these roles, but you'll recognise the function:
Product Owner: functionally responsible for delivery of business processes enabled by the platform, and must know the business. If you want to get the best solution, then pull the best people out of the business to drive it.
Platform Owner: has technical ownership of the platform and must know the platform. Support them, invest in their enablement, and get them on the Salesforce Architect certification track.
Give both of these roles long-term objectives outside of the immediate project deliverable and they can drive the right behaviours in their teams. Salesforce Admins and Developers should be up to date on the platform and default to no- or low-code solutions. Where code is written it should follow patterns, and be reusable, documented and well tested.
For all of the variation across different businesses, a large proportion of business solutions can be built from a much smaller number of common components. Strong adoption of good patterns avoids the unhealthy divergence that happens when the same thing is built multiple times in different ways by people who don’t talk regularly.
The Salesforce platform is itself a collection of reusable patterns: Process Builder to deliver automation, Custom Objects to extend the data model, Lightning Component Framework to create a consistent user experience. All of these are strong functional patterns.
But a powerful platform also means there are different ways to do similar things: process builders, workflow rules, visual flows, Apex and AppExchange tools all provide different approaches to implement custom business logic.
Your Salesforce solutions need to adopt consistent patterns for your business. What sequence will your approval processes follow? What is your common approach for authenticating and authorising different integration flows?
Identify those patterns that appear frequently across your business and have a high impact on velocity, then invest in making these patterns strong. Once you have identified these 'best buy' patterns, ensure they are discoverable by the delivery team and used consistently.
How often have you seen this story play out in an ‘agile’ enterprise program? The business identifies a need that's going to take some effort to deliver. A project is stood up and does some discovery. The team identifies 100 user stories and estimates a rough velocity of 20 stories per sprint. So five 'sprints' are planned and a delivery date is committed all the way up to the big scary boss. Two sprints in, the project team is already scrambling and talking about cutting scope. A familiar tale?
A major objective in moving to an iterative, more agile way of working is to learn from the build as it progresses, constantly checking in to ensure you're building the highest-value solution. Yet this common waterfall/agile hybrid approach, with minimal possible delivery effort and fixed delivery milestones, removes any space for learning, adapting, refactoring and reflection. It is a recipe for technical debt.
In my experience, the most effective delivery teams spend 30% of their time on long-term improvements to the solution. That is, 30% of time not directly delivering new functionality, but instead refining and refactoring the already built solution – including paying off those tech debt stories captured earlier – plus improving ways of working and strengthening delivery capabilities.
In planning mode at the start of a project, allocating resources away from new features feels like a huge investment. But the payback over time is improved velocity and reduced entropy.
Teams that don't invest in improvements quickly burn more than 30% of their time dealing with debt. By allocating time upfront and tracking debt, you can consciously decide on the right level of refactoring and keep on effectively delivering a high-value solution, instead of building compromised features on shaky foundations.
Most inadvertent, reckless technical debt is caused by not knowing there is a better option.
The Salesforce platform is big and it moves fast, with 56 major seasonal releases and counting. To get full value from the out-of-the-box capabilities of the platform, you need people who know what can be done, what should be done, and what is coming next.
The Customer Success Group at Salesforce deliberately embeds continuous learning into the culture. Every role has a defined learning path with required Certifications, Trailhead badges, internal courses and peer-learning. With every Salesforce release, this learning path evolves, and staying up to date is a key metric.
Most of these learning resources are available to the whole Salesforce Ohana. Our most successful customers install Trailhead Tracker and evangelise the self-directed learning on Trailhead; they encourage and reward Salesforce Certifications so that they know their team are staying up-to-date with maintenance exams; and they use the whole Success Cloud for specialist services to develop their delivery skills.
On my inherited disaster, we didn't have the advantage of three ongoing releases per year delivering innovation, but we did manage to drag it out of the worst depths of the black hole by identifying and tracking the debt, getting the right people to prioritise value, and allocating time to paying back the debt. It was a hugely painful exercise and the opportunity cost from the years of missed productivity was monstrous.
Don't fall into the trap.
The APAC Employee Engagement Report shares insights to support IT and people leaders as their businesses accelerate to growth.
Stuart Hamilton is Senior Director, Program Architect at Salesforce. Read more from Stuart and from the Advisory Services team.
