As a project manager or project owner of a software development project, Technical Debt (also sometimes referred to as Code Debt) can be difficult to detect the presence of and manage. Technical debt should not be confused with technical risk, technical debt and technical risk are related but not the same.
In this blog post, I will focus on technical debt and share some tips and tricks to identify and manage technical debt in any software development project as a project manager.
What Is Technical Debt?
The term is defined on Wikipedia as:
“Technical debt (also known as design debt or code debt, but can also be related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”
I like this definition because it highlights that technical debt is introduced when shortcuts are taken by the developer/development team (whether intentionally or not) to complete some development tasks.
The long term cost of cutting corners is that making changes to your project’s codebase in the future becomes increasingly more difficult, and these future changes take more time than they should. In a nutshell, technical debt means: save time now to spend time later.
Common Causes Of Technical Debt
Unreasonable Deadlines
Writing custom code takes time, your developers need to take your ideas and convert them from a concept to a functionally working and visually beautiful software application.
This requires architecting, implementing and testing. The more complex the problem, the longer each of these steps will take, and therefore the longer time required overall.
Rushing the design/architecting process could end up with a software solution that does not meet its requirements correctly. Another potential result could be that the wrong software frameworks/technologies are chosen upfront, which does not cater for all the project requirements.
If the implementation/coding process is rushed, the developers may be forced to take shortcuts in some areas of the code and write messy code. This may end up with the same initial result with a faster implementation, however, at the expense of making future changes.
Finally, if the testing phase is rushed, serious bugs could make their way into the production version of your software. Sometimes getting to market earlier with some bugs or some technical debt is somewhat acceptable, however, this must be a continuous decision.
Developer Expertise
Junior developers have a tendency to write messy code, most of the time because they don’t yet have the experience and expertise to write clean code. Messy code introduces technical debt because at some point, when the code needs to be extended to add new features, it will either need to be refactored or more messy code is written, creating even more technical debt.
You’ll be forgiven for thinking that a developer with many years of experience = a strong developer who cannot write messy code, that unfortunately is not the case. Many experienced developers have never learned how to write clean code. Don’t worry, there is hope, there are ways in which you can manage technical debt.
How To Manage Code Debt
Pair Juniors with Seniors
Junior developers should not be left alone to write code without adult supervision. Assign a senior developer to review all code written by the junior and coach them on errors they may have made and help them refactor their code to remove any technical debt that might have been introduced.
Encourage Code Refactoring
Give your development team the freedom to refactor messy code if they come across messy code in the codebase. Sometimes a refactor could take days or even weeks to implement, so it is also wise to allow freedom to refactor within some time frame bounds.
For bigger refactors, you would need to weigh up the value of the refactor vs the time sync and make a decision accordingly. Lots of small refactors over time makes a big difference to the state of the code.
Talk to your Developers
Developers know what areas of the code are ‘difficult’ to work on. A general rule of thumb is that if code is ‘difficult’ to work on, it’s because there is some technical debt that can be improved via a refactor.
Ask your development team which parts of the codebase are pain points and what it would take to refactor them. Once you have a better understanding of the problems and what it would take to refactor this code, you can make informed decisions whether the refactor is worth the time sink.
Plan Reasonable Deadlines
We all want our software to be done yesterday, 100% bug free with 0% technical debt. Unfortunately, we live in the real world and custom software takes a long time to be built correctly. Developers also love to overestimate their ability, so if a developer says it will take them 1 week, plan for 1.5–2 weeks.
Don’t forget to plan for testing and refinements. A task which is code complete is not ready for production, this code should be tested by the project manager before it is pushed to production. All these steps take time and must be appropriately catered for.
Working As A Team To Win
Technical debt grows slowly over time. At first, it might seem like it does not matter, but as a project’s codebase grows over time, if technical debt is not managed it can end up being unmanageable. It could reach the point where it is cheaper to start again from scratch than to try and fix your codebase with heaping mounds of technical debt.
As a project manager, it’s your responsibility to pick up on signs that technical debt could exist in your project and allocate time for refactoring. Make sure that you are working with an experienced and capable team of developers to give your software development project the highest chance for success now and in the future.
If we work together, the chances of generating technical debt are mitigated. This is what we believe at Appstrax. For us, having a collaborative relationship and clear communication with our clients is paramount.
