Navigating tech choices and the cloud vs. on-premise decision in our data-driven world.
Have you ever heard of the term Technical Debt? As a team have you ever placed a solution into production, which was built as a Proof of Concept (POC) on a platform that was not finalized yet? In both situations, you’ll end up with a solution that is not officially done and ready.
Building something with Technical Debt is not a problem as long as it is removed, or improved, at a later moment in time. To be honest.., it rarely happens and remains forever. Let’s dive into what it is. Wikipedia defines it as:
“The implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”
How it affects your team and solution
Technical Debt blocks you and your team from quickly adding new functionality. When implementing a POC or a Minimum Valuable Product (MVP) there is no shame in taking shortcuts. It is not necessarily a bad thing to get projects moving.
Bringing MVPs live earlier with Technical Debt can help determine the product/market fit sooner. It also helps to quickly receive feedback and you can meet the customer requirements faster. This is called Planned Technical Debt. In the end, if the solution delivers the main requirement, the customer is happy!
Next to this, there is also the concept of Inadvertent Technical Debt, which occurs when code is brought into production while engineers don’t fully understand the requirements, code review did not happen, or management is pushing. This is a bigger problem since the main requirements are not delivered and the customer is not happy. Secondly, as it was not expected, there is no time planned soon to solve it.
"Although it does not add any business value at that moment, it will save you from problems afterwards."
In both cases, planned or inadvertent, the pain comes afterwards. Experience teaches us that once it is brought into production, the focus on resolving it is gone. At that moment other requirements will be prioritized.
In the realm of ongoing development, teams face an escalating cost associated with deferring the resolution of technical debt. The longer a team procrastinates, the higher the eventual cost. Delaying the addressing of it leads to an accumulation that jeopardizes project deadlines, making it progressively challenging to estimate the effort required for resolution.
Surprisingly, substantial technical debt can be associated not only with Proof of Concept (POC) or Minimum Viable Product (MVP) phases but also with solutions actively running in production. As long as a solution operates without errors, the debt might persist indefinitely, hindering long-term sustainability.
Various factors contribute to the introduction of technical debt, making it imperative to focus on strategies for addressing and managing it within teams and solutions. Some teams adopt a dedicated approach, consistently refining existing solutions. However, it's common for solutioning teams to tackle their own debt, especially in smaller organizations. It's crucial to have senior engineers play a pivotal role in systematically enhancing the codebase, leveraging their comprehensive knowledge of the business domain and existing solutions.
Effective communication between teams is paramount to maintaining alignment. When solutioning teams take on the task of eliminating their technical debt, allocating dedicated time within the team becomes essential. Whether it's a full sprint within a specific period or a set number of scrum points per sprint in an Agile environment, ensuring consistent attention to addressing technical debt facilitates continuous improvement.
Encouraging teams to prioritize the resolution of technical debt in every sprint fosters a culture of frequent improvement. This practice enhances proficiency in code refactoring and serves as a preventive measure against the accumulation of technical debt in future projects. The mantra becomes, "Always address and improve technical debt rather than allowing it to persist unchanged."
Having Technical Debt in your solution is something that we all will encounter. At first thought, it is not that bad. However, you need to make it a habit to resolve it. Otherwise, it will remain forever and possibly degrade your awesome software.
Make sure to improve your team and solution continuously by allocating dedicated time for solving your Technical Debt. Although it does not add any business value directly, it will save you from problems in the future. It sounds simple, but it is hard sometimes, trust me!
Let us know what you think of this!
Reach out to us: email@example.com
Or join us: workatffa.com