Technical debt is a term that many software engineers have already heard, but on which they have divergent definitions. In most cases, it refers to:
- Issues that developers face when working on their source code, impacting their organizations' business.
- Technical decisions made in the past that currently impact software maintenance and evolution.
- Time spent on unplanned work (bug fixes, maintenance tasks, ...), which is a very interesting perspective.
We also hear about accidental technical debt (or complexity) and mastered technical debt. In the second case, people knew exactly what they were doing, were conscious of their acts, and planned remediation actions.
When we talk about methods and tools in technical debt management, they fall into three categories:
- Automated software mining to estimate technical debt and code complexity (usually post-commit/push analysis)
- Preventing technical debt creation by helping developers before they push code
- Identifying manually technical debt and planning remediation actions
In this post, we narrow the focus on developers’ operations that introduce risks of code quality issues and require future rework.
✋Best practices prevent code issues
To avoid such facets of technical debt in our code, all developers should ideally know and follow the best practices in software engineering (in topics ranging from Clean Code, Architecture, Security, Performance, a language, or a framework, ... quite a challenge, isn't it?)
Moreover, best practices are not always universal but contextual to an organization or a project. If you welcome a new developer to your team, they’ll have to get familiar with your codebase and best practices to avoid introducing technical debt.
📖 Learn to avoid accidental complexity
It seems fair to assume that developers, like anyone else, try to do their best in their daily work. Developers who introduce technical debt are likely to do it accidentally because they were not aware of the best practices.
Thus, one solution to prevent technical debt creation is to improve developers’ skills and knowledge regarding the best coding practices in their context.
📝 Define and share our best practices
Two challenges arise in that context:
- How to create a repository of best practices?
- How to make sure this knowledge is spread to all developers?
We know that code reviews or pair programming practices are relevant to sharing technical knowledge among developers.
But they’re less efficient persist knowledge over time and discussing it with other developers in a team and an organization. We also know that Wiki tools, such as Notion or Confluence, have limitations for managing best practices.
That’s where Packmind goes on stage!🚀 This solution is designed to define, share and learn best coding practices for software developers in your organization.
📝 Connect developers’ knowledge to prevent technical debt
Packmind comes with a simple process to continuously improve our best practices:
#1. Let every developer suggest best practices thanks to our IDE and Web browser plugins for code review.
#2. Regularly discuss and assess best practices during a Craft Workshop to decide which practices to follow. During a Craft Workshop, each contributor presents their best practice proposal:
#3. Get automatic suggestions in your IDE and during a code review if some best practices are not followed
Packmind provides built-in features to onboard new developers on best practices, but this will be covered in a future post.
✨ Time to act!
We saw in this post how to limit the introduction of technical debt due to best practices ignorance and non-compliance. Of course, all this process is hard to be 100% automatized. The SOLID principles, for instance, are tricky to detect using static analysis. However, they can be documented with concrete examples and counter-examples on your project, and developers can learn from this documentation in Packmind.
Get started on Packmind for free!
Top comments (0)