Addressing Technical Debt in DevOps?Projects
Product owners trying to balance features and tech debt

Addressing Technical Debt in DevOps?Projects

While developing products in DevOps teams, we take decisions on which features to develop, how to ship them quite quickly, in order to meet the customer requirements. Often these decisions causes more problems in the long run. These kind of decisions lead to “Technical Debt”.

Tech debt is phenomenon which happens when we prioritise the speed of delivery now, by forgoing everything like code-quality or maintainability. Although the agility of delivery of products is key to stay relevent in this agile world, but we have to make decisions also that the changes are sustainable.

In this article, we'll talk about what technical debt is, how to handle quick decisions during development, and give examples to help you understand how to avoid future issues.

Tech debt is the extra work we has to be done later because of the technical decisions that we make now. Although it was coined by software developer Ward Cunningham in 1992, but it's still holds relevance .

Usually, Technical debt occurs when teams rush to push new features within deadlines, by writing write code, without thinking about other considerations such as security, extensibility etc. Over the time the tech debt increases and becomes difficult to manage. The only way to deal with tit then becomes to overhaul the entire system and rewrite everything from scratch. To prevent this scenario we need to continuously groom the tech debt and to that we need to understand the type of tech debt we are dealing with.

Causes of Tech?Debts:

Value to customer vs Cost of solving it

Prudent and deliberate: Prioritising swift shipping while postponing dealing with their consequences is deliberate debt. This can be taken up when the product is still in MVP phase or the benefits of quick delivery outweigh potential risks.

Reckless and deliberate: Inspite of knowing how to craft better code, prioritising rapid delivery over quality leads to reckless and deliberate debt.

Prudent and inadvertent: Prudent and inadvertent debt occurs when there's a commitment to producing high quality code, but this solution was discovered after the feature has been shipped.

Reckless and inadvertent: Reckless and inadvertent debt arises when team tries to implement the coding best practices without actually understading how or why to implement it. This often leads the teams making a different kind of tech debt.

Given these different causes for tech debts, lets try to understand the types of tech debts. These can be broadly categorised under three main heads

Types of Tech?Debts:

Code Related?Debts:

  • Code Debt: When we talk about talk debt, code debt is the first thing that comes to the mind. It is due to bad coding practices, not following proper coding standards , insufficinet code documentation etc. This type of causes problem in terms of maintainability, extensibility, security etc.
  • Testing Debt: This occurs when the entire testing strategy is inadequate , which includes the absence of unit tests, integration tests, and adequate test coverage. This kind of debt causes us to loose confidence pushing new code changes and increases the risk of defects and bugs surfacing in production, potentially leading to system failures and customer dissatisfaction.
  • Documentation Debt: This manifests when documentation is either insufficient or outdated. It poses challenges for both new and existing team members in comprehending the system and the rationale behind certain decisions, thereby impeding efficiency in maintenance and development efforts.

Architecture Debt:

  • Design Debt: This results from flawed or outdated software architecture or design choices. It includes overly complex designs, improper use of patterns, and a lack of modularity. Design debt creates obstacles to scalability and the smooth incorporation of new features.
  • Infrastructure Debt: This is related to the software’s operational environment, including issues such as outdated servers, inadequate deployment practices, or the lack of comprehensive disaster recovery plans. Infrastructure debt can lead to performance bottlenecks and increased downtime.
  • Dependency Debt: This arises from reliance on outdated or unsupported third-party libraries, frameworks, or tools. Such dependency exposes the software to potential security vulnerabilities and integration complexities.

People/Management Debt:

  • Process Debt: This relates to inefficient or outdated development processes and methodologies. It includes poor communication practices, a lack of adoption of agile methodologies, and a lack of robust collaboration tools. Additionally, not automating the process can greatly affect the software delivery’s agility.
  • People/Technical Skills Debt: This occurs when the team lacks essential skills or knowledge, resulting in the implementation of sub-optimal solutions. Investing in training and development initiatives can help reduce this type of debt.

Managing and Prioritizing Tech?Debt

Technical debt is something that happens when teams are developing products in aglie way. It's like borrowing against the future by taking shortcuts now. But if the team knows about this debt and has a plan to deal with it later, it can actually help prioritise tasks. Whether the debt was intentional or not, it is crucial that the team grooms the technical debt during a backlog refinement session.

Here's how you can categorise these tasks:

  1. Do It Right Away: These are tasks that are crucial for keeping the product running smoothly.
  2. A Worthy Investment: These tasks contribute to the long-term health of the product, like upgrading outdated systems.
  3. Quick and Easy Wins: These are small tasks that can be fixed easily. They're great for new team members to learn about the product.
  4. Not Worth Considering: Sometimes, the problem might solve itself or it might not be worth the time and effort to fix, especially if you're planning to upgrade or retire a system.

When building a new product/feature or facing tight deadlines, it quite common to choose speed delivery over the quality or code sustainability in the long run. Striking balance between the need for quick solutions while maintaining the long term vision for sustainable development practices is the key. Managing technical debt effectively can help ensure the success of your projects in the long term.

要查看或添加评论,请登录

Krishnadutt Panchagnula的更多文章

社区洞察

其他会员也浏览了