March 2, 2023 Some may argue that Software development is exempt from the majority of physical laws. However, the inevitable rise in entropy has a significant impact on it. Entropy, a term borrowed from thermodynamics, denotes the level of disorder within a system. The laws of thermodynamics guarantee that the entropy in the universe is constantly increasing. When software becomes more disordered, it’s referred to as “Software Rot.” Others may call it “Technical Debt,” a term that implies repayment in the future. Nonetheless, both rot and debt are prone to spread uncontrollably. But for this post, instead of using “Software Rot” term to describe the inevitable deterioration of software as it’s modified over time, let’s use a more ambiguous and “softer” term like “Technical Debt”. When things are going wrong with your software, the last thing you want is to use a straightforward term that accurately captures the situation. No, no, let’s make sure we sugarcoat it as much as possible to avoid any unpleasantness. After all, who needs reality when we can have euphemisms instead? In our experience, we’ve noticed that teams often delay improving their software until they have more time, while adding new features to it. However, they eventually realize that this time for improvement work never comes. This leads to a pile-up of work that becomes increasingly challenging as the software product expands. One reason for this is an increase in “Software Entropy” which is a measure of instability or disorder in a software system resulting from making changes to it. In other words, it’s an indicator of how challenging and expensive it is to maintain software as it’s modified. Research on software entropy confirms that software becomes increasingly difficult and costly to maintain as it’s modified. This increase in software entropy is often referred to as technical debt. In the Salesforce world, the code and configuration are not immune to changes that occur during implementation. This is because features may become outdated, programming languages may evolve, and new out-of-the-box features may be introduced. Additionally, code and configuration are not always backward compatible, meaning that even if we intend to maintain the existing source code or functionality of a software system, we must still prepare for changes in its dependencies, programming languages, and software platforms over time. In short, it is essential to anticipate and adapt to changes, rather than trying to prevent them altogether. First, let’s debunk some common myths and shed light on the truth. Myth #1: There are some common misunderstandings regarding technical debt as it relates to Salesforce, with some people believing that it is only related to code. However, this is not accurate. Technical debt can arise in even the most low-code implementations. Myth #2 Many organizations mistakenly believe that technical debt is simply a result of poor code quality in general. However, this is a dangerous fallacy because it can lead to the wastage of time, people and money on improvements that may not be essential or have a clear business outcome. As a result, it is important to understand the true nature of technical debt and avoid making incorrect assumptions about it. To give you a better understanding of what Technical Debt is, here are some examples: Example #1: When administrators create fields and page layouts that become difficult to manage or when solutions are implemented for current problems that are unable to address future requirements, necessitating a complete overhaul. Example #2: Technical debt can also relate to architecture, where attempts to keep the data model denormalized by adding fields on the object can become unsustainable as requirements evolve, requiring significant adjustments to processes, flows, pages, and reports. Regardless of whether it involves configuring or customizing, technical debt is a normal part of software development. The key is to manage it effectively and maintain the appropriate balance. How bad it can get? Consider a type of code known as “legacy code” that lacks any artifacts to convey the intent of its creators and developers and emits a foul odor. It may lack tests or have poorly written ones, inadequate documentation, minimal or no comments, and little effort to assist new reviewers, engineers, or developers in comprehending its functionality. As a result, modifying or collaborating with this type of code can be challenging. It can get really bad! Apocalyptically bad! Prior to improving software that has deteriorated to the point where maintenance has become a nightmare, we need to clean up the system, enhance its structure, and decrease its entropy. It’s important to recognize that nobody intends to create a software that has become difficult to manage over time. Why Technical Debt Occur? There are various reasons why technical debt occurs. Sometimes teams intentionally take shortcuts for various reasons like tight deadlines, proof of concept, end-of-life considerations, tactical moves, or last-minute rushes. In other cases, this can occur due to a lack of experience, inadequate governance, lack of architecture principles, or a focus on short-term goals rather than long-term solutions Moreover, technical debt can also arise due to A “Done is better than perfect” mindset (although this may not align with the views of Agile advocates). But even though it was done deliberately, it’s still considered “debt,” and you’ll need to pay it back eventually or else you’ll get hit with extra fees and interest later on in the product’s lifecycle. So it’s crucial to manage your technical debt well. And just to be clear, it’s not always a bad thing to owe! What is the Impact? The impact of technical debt can manifest in several ways, and it can have a significant negative impact on software development projects. Here are some examples: Code/Config Debt: poorly written code/config Architecture/Design Debt: insufficient abstractions or lack of separation of concerns API Debt: poor error handling and slow response times Quality Debt: limited automation, inadequate code coverage, and insufficient operational and performance testing Infrastructure Debt: outdated equipment that is not scalable and can be unpredictable Reduced value flow in software development Increased friction between teams Demotivated teams due to the unpredictability of their efforts, leading to higher attrition Reduced production stability that may result in the loss of key business activities or revenues Circular dependent code or config that is difficult to modify without unintentionally breaking the build Code or config that becomes increasingly challenging to unit test, which distorts the test pyramid and necessitates manual testing Business Impacts of Technical Debt If we consider the impact of technical debt over time, its magnitude increases the longer it remains unaddressed. A small refactoring or reengineering task can escalate into a larger modernization or replacement project in the future. To manage technical debt, the Service Maintenance Engineering team must play an active role. Several business losses can arise from technical debt, such as: Increasing operational costs, impacting the cost-to-business budgets Slower time to market, which may result in losing out to competition, particularly in the fintech ecosystem Risk of missing regulatory deadlines Poor project plans Difficulty in estimating the impacts of a change due to the layered technology landscape Poor controls, which are prone to slippage Inadequate application security Customer-facing applications may not perform well, leading to unhappy customers Multiple sources of data may require numerous tactical adjustments The decision-making process may not receive the right quality insights How to Manage Technical Debt Managing technical debt is a continuous and ongoing process, requiring a long-term approach. Continuous reduction of technical debt can be achieved through various approaches – strategies for ongoing technical debt reduction. In order to prevent the team from slipping back into these old habits and creating more debt it’s crucial to cultivate a mindset that makes it exciting and fulfilling to improve the code. By doing so, the team can be motivated to make the necessary changes and avoid repeating past mistakes. The three stages of technical debt reduction are: Refactor: Refactoring is the process of improving the internal structure of existing code without changing its external behavior. Rewrite: If the technical debt is too high and the codebase is too complex to refactor, a complete rewrite may be necessary. Replace: In some cases, it may be more efficient and cost-effective to replace the existing codebase with an off-the-shelf solution or a third-party library that provides the same functionality. It’s worth noting that these stages are not always linear or sequential, and the best approach may depend on the specific circumstances of the codebase and the goals of the development team. To effectively manage technical debt, we recommend to allocate a portion of each sprint specifically to address it. Setting aside 10-15% of sprint capacity for technical debt reduction can help ensure that it’s addressed on an ongoing basis and prevent it from accumulating over time. To reduce technical debt on a continuous basis, a prioritized list of technical debt items should be combined in parallel with the development backlog, while also continuously monitoring for both known and unknown technical debt items. Finally, it’s important to note that blaming your colleagues for their mistakes is not a helpful approach. Speaking negatively or sarcastically about the codebase is also unproductive and can harm team morale. Rather than criticizing, take action to reduce the entropy of the project and work towards solutions that benefit the team as a whole. It’s important to maintain a positive and constructive attitude in order to keep team spirit intact.
