Technologies have become the primary vehicle of progress, which is true. However, there’s also the flip side of the coin: early subpar technological choices, if left unpruned, can result in technical debt. It may even lead to higher development costs, long time-to-market, and reduced productivity. With so much at stake, managing technical debt should be a priority both for CTOs and software developers.
This article will answer some critical questions about technical debt. It describes what technical debt is, what its causes and impacts are, lists some common types of technical debt, and highlights what it means in Salesforce.
Technical debt (TD) refers to the practice of implementing shortcuts during software development to achieve short-term results at the cost of efficiency in the long run.
In other words, it’s the result of prioritizing speedy delivery over perfect code to expedite production.
It usually occurs when a developer relies on sub-optimal coding solutions to meet a deadline or deliverable but "gets into debt" that they must pay back with future reworks.
Ward Cunningham, the author of Agile Manifesto, first coined the term 'technical debt' to describe the impact of accruing tech issues.
He described this concept in 1992 which follows as:
"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."
The concept does not imply that debt should never be incurred. Just as leverage can benefit an organization when used correctly, a quick solution can mean a faster time to market in software development. Therefore, technical debt is not necessarily an issue, but it can become one if the software product isn't optimized properly or have excessively dysfunctional code.
Steve McConnell, Chief Software Engineer at Construx Software, introduced two major categories of technical debt:
Intentional
Unintentional
1. Intentional technical debt
It happens when the organization makes a conscious decision to generate some technical debt with a full understanding of the risks and costs associated with it. In this planned technical debt, it is crucial for the organization to be as precise as possible in defining the compromises that it intends to make.
2. Unintentional technical debt
On the other hand, unintentional technical debt occurs due to a lack of knowledge, accidental mistakes, or—in some cases—poorly sub-optimal codes that are made out of expediency. An example of unintentional technical debt can be a poor design approach that turns out to be error-prone. This type of debt sometimes occurs due to poor communication within an organization or DevOps teams.
Later, technical debt was classified into 13 distinct types by some academics in 2014, including:
There are four different root causes of technical debt—referred to as the technical debt quadrants. The four technical debt quadrants were first introduced by Martin Fowler which include reckless, prudent, deliberate, and inadvertent.
The purpose of assigning the technical debt to these quadrants is to understand the intent and background of code issues. While some code debt may be deliberate and categorized as good debt, others may be inadvertent and classified as bad debt.
There are several ways an organization can accrue technical debt, but some causes are more likely to occur over a project lifecycle which include-
1. Utilizing outdated design even though the business needs have changed.
2. Leveraging bad coding practices when configuration options are readily available.
3. Poor code quality, which leads to failed deployment and app crashes.
4. Letting good tech debt foster for too long.
5. Pressure from stakeholders to release the app soon, without making necessary changes.
6. Insufficient testing, which leads to quick band-aid fixes.
7. Coding without supporting proper documentation.
8. Inadequate technological leadership.
9. Last-minute changes to specifications.
10. Lack of expertise and skill gaps.
11. Misalignment of funding and strategy.
12. Lack of flexibility.
13. Running parallel development projects, as it creates extra work while merging the changes into a single source.
14. Not following industry standards.
15. Lack of collaboration between team members and stakeholders, hence affecting efficiency.
Technical debt is inevitable and can be good in a particular case (e.g.: rapid MVP development for market validation). However, it has its downsides, resulting in real expenses that drag cash and profits, restrict flexibility, and can become burdensome that it could ultimately lead to insolvency.
Increased technical debt impacts an organization in several ways, including:
1. It lowers the team’s productivity
The impact of technical debt is exponential, not linear. It highly affects teams' ability to innovate and execute new ideas as they get busier in fixing the technical debt than delivering the value. They spend hours, maybe days, wrangling the quick-and-dirty code to get the product to a state in which future modifications won’t be a painful effort or crash the system. This eventually leads to lower productivity and increases 'Time to market".
2. It negatively affects customer experience
Technical debt contributes as a negative value for the organization in terms of system downtimes, bad user interface, lower system performance, etc. that highly impact customer satisfaction.
Read more: How to create a better customer experience with Salesforce?
3. It Impacts transparency within the organization
Technical Debt can have a negative impact on the quality and the progress of product development, if not understood properly. It is like a hidden cost that can lower efficiency which impacts predictability. It further creates problems for both the development team and product manager to estimate the time and effort required to build new features, release plans, and product roadmaps. Because the estimates are flawed, this ultimately decreases transparency.
4. It lowers the morale of developers
Technical debt impacts the whole organization, but it especially affects the developers. According to The “State of Technical Debt 2021” report, 52% of engineers believe that technical debt negatively impacts their team’s morale. As more tech debt means more bugs, lower performance, system downtimes, slow delivery, lack of predictability in estimations, and therefore less time to work on new innovative projects. This sometimes creates unnecessary pressure from the management and questions developers’ productivity and skillset. As a result, it can demotivate employees.
5. It increases the Total Cost of Ownership(TCO)
Technical debt has a major impact on the TCO and the return on investment (ROI) of the organizations. When technical debt accumulates, systems become more complex, with overlapping processes and customizations. As a result, the product becomes costlier to maintain over time. Organizations start to spend more time, money, and resources to fix problems, instead of closing sales and acquiring new customers.
Technical debt consumes 40% of development time and the cost of ‘Technical Debt’ is estimated to be more than $1 Million on average per business application.
Traditionally, developers would incur technical debt by taking shortcuts in code, but now with low-code platforms like Salesforce, technical debt is created just by clicks as well as code.
In Salesforce, technical debt extends beyond code and includes overlapped processes, excessive custom fields, redundant cruft, and incoherent configurations. It occurs when coding or customization decisions are based on time, budget, and simplicity, rather than strategically addressing the needs of the entire organization.
Examples of Salesforce Technical Debt
The most common examples of technical debt we see in Salesforce environments include-
1. Hard-coded references
2. Unused validation rules
3. Row lock errors
4. Outdated reports and dashboards
5. Inactive workflows, and
Legacy applications
Managing technical debt in Salesforce is a challenge almost all organizations face. As Salesforce partner organizations become unmanageably complex over time, it can lead to slow performance, sluggish adoption, reduced agility, disruptive administrative turnover, and failed development projects. As a result, the cost of technical debt will be extremely high.
According to a McKinsey report, approx 20%- 40% of survey respondents' technology estates are attributed to technical debt. Most large organizations “owe” millions of dollars in unpaid tech debt.
However, a small amount of technical debt in Salesforce is acceptable, but a pile of debt can have a major impact on the TCO. The more technical debt accumulates, the less ROI organizations acquire from their Salesforce investment.
Having zero technical debt is a myth. It isn't a bad practice but without proper management, your organization can become crippled with technical debt over time. While the type of debt payoff is different in each scenario, building an effective strategy can help pay off your debt faster. So, the sooner you start alleviating the detrimental impact of tech debt on your project, the sooner you will be able to keep up with your competitors.
Daffodil helps organizations reduce technical debt, clean data, and optimize Salesforce to get the most value from the platform. Our experts will understand your goals to deliver an entirely customized roadmap that enables you to ramp up your release cycles—and drive your business forward.