As a starting point, we can say roughly that technical debt is all those decisions we make during software development that narrow down our capacity as a team to create new features that add value to the business.
In the same way we say every printed document is automatically obsolete we can say that first-time shipped implementation is like going into technical debt
Technical debt is often asymptomatic, making it difficult to prioritize, but once the symptoms appear, it may be too late and the associated costs may be much higher.
Table of contents
- Sort of technical debt
- What about the good technical debt?
- What are the consequences of technical debt?
- Are defects technical debt?
- Is the development environment configuration technical debt?
- Technical debt and product management
- How much technical debt do I have?
- How to estimate the impact of technical debt
- Final thoughts
Sort of technical debt
I’m sure the following list is familiar for you. Don’t worry, you are not alone.
- Known tolerable bugs
- Bad user experience
- Tolerable security issues
- Obsolete release process
- Missing automated backups
- Missing or bad configured alerts
- Performance issues
- Legacy systems
- Unreadable code
- Missing or poor automated tests
- Outdated documentation (if any)
And likely there are much more, even different flavors of the same item
What about the good technical debt?
Not all is negative when we talk about technical debt, there is also good technical debt. Think for example when you borrow some money to achieve a goal such as buying a car.
In software development, we are all experts on “borrowing money”. Our problem comes when we accumulate technical debt in the same way we accumulate money debt in our life.
Let’s say then that we want to deliver something quick to close a deal or tolerate bad performance because the hardware is cheap. For a couple of months that can be good technical debt but if we scale and we do not start over again, that will be the bad one
What are the consequences of technical debt?
People don’t want to work with spaghetti code or in a project that is not well organized. So a big consequence is team rotation which comes with more frequent onboarding periods which generates low team productivity. Also, these kinds of projects make people think they are not adding value to their own careers and feel stuck all the time which makes them feel unmotivated.
Delayed delivery. Every new feature will be delayed because of technical debt due to our time will be consumed on troubleshooting existing issues or because of a poor release process. Instead of making analysis or coding, our team is dedicated to resolving that performance issue that is making our users stop using our product
User experience is everywhere. Technical debt related to the poor user experience could cause a gradual decline in the use of our product by users.
Are defects technical debt?
The short answer is: it depends. Let’s say users are unable to make payments or unable to add products to the shopping cart. That’s a huge bug and cannot be considered debt because your business depends on it.
On the other hand, if the shopping cart has a button whose style does not 100% respect the company’s branding, that is something that could be considered technical debt. Unless the button’s color represents the branding of our competitor 🙂
An example where seems to be a gray area and needs to be addressed
While most will agree that known, unaddressed vulnerabilities are a type of technical debt, it is questionable if a newly discovered vulnerability is also technical debt. The key here is whether the security risk needs to be addressed and, for that answer, we can look at an organization’s service level agreements (SLAs) for vulnerability management. If an organization sets an SLA that requires all high-level vulnerabilities to be addressed within one day, then we can say that high vulnerabilities older than that day are debt.
Measuring Technical Debt
Is the development environment configuration technical debt?
Yes it is!
It doesn’t affect directly business but it affects new team members’ ramp up or existing members’ reconfiguration for example when a computer has broken. We should have a clear guide about development environment configuration. It must describe all the steps necessary to start adding new code and test it locally. Also, the development environment shouldn’t so complex, It cannot take an entire day to get up and running
These kind of things should be described in your guide (ideally the default readme file in your repo)
- Necessary software pre-installed needed such as JRE, Node.js, etc
- Recommended IDE(s) the team uses. I know this should be agnostic but the team can collaborate better
- Environment variables o be set. There are some default and non sensitive variables that can be share in the repo. For the sensitive ones please provide direction (a contact, a team role) about how to get them
- Docker configuration if the useam uses it
Technical debt and product management
One of the most difficult things as software engineers is to argue about technical debt. Many times the arguments are made more difficult when there are conflicts between the development team and the product manager. Mistrust between work teams is always the enemy of any valid argument
The following exchange should be familiar. The product manager describes the next feature they want to be added to the product. Developers give a high estimate for the time it takes to implement, which is seen as too long. The developers talk about having to deal with the implications of making changes to lots of hard-to-understand code or working around bugs in old libraries or frameworks. Then the developers ask for time to address these problems, and the product manager declines, referring to the big backlog of desired features that need to be implemented first.
Managing Technical Debt in a Microservice Architecture
Provide context and be sincere about why we arrived at this point is the best bet to get that time you need to fix or improve that annoying piece of code.
Most persons involved with software development have faced difficulties trying to get product or project managers to agree to let them spend time fixing their project’s technical debt.
Managing Technical Debt in a Microservice Architecture
How much technical debt do I have?
Adding new functionality in a product with little technical debt as in a product with several development sprints and a lot of accumulated technical debt.
Here is where a good bunch of tests can save us from headaches. Unit tests with good code coverage and integration tests are the minimum to increase chances of success, otherwise adding new code will become harder and harder.
Knowing how much technical debt you have will allow you to think better about the impact of adding new features and new members in case of delivery delays. But remember that 9 Women Can’t Make a Baby in a Month. Sometimes adding new members is not the best decision.
How to estimate the impact of technical debt
If adding a new feature in a context of huge technical debt, imagine how hard can be to reproduce and fix a bug. That’s why is important to know how much time and money we spend on tasks related to a specific technical debt.
Estimation is not an easy tasks but at least we can narrow down our cost to have an idea. Here we have some clues:
(…) we can therefore calculate the cost for this type of debt relatively easily by looking at the cost of support activities related to the issue and adding that to the impact on productivity for the development of new code. The cost of the debt can also be easily calculated by looking at the time and resources required to fix the problem.
Measuring Technical Debt
As an estimate, let’s say this work would cost $10,000 to mitigate. Comparatively, due to the issue, the entire team, incident management and operations center took one to two hours per week remediating the impact. Let’s estimate this cost at $2,000/week. Based on this high-level analysis, it is clear that the ROI for fixing this defect would be realized five weeks after fixing the bug.
Measuring Technical Debt
Final thoughts
A project can fail for many reasons: miscommunication, lack of expertise, bad business decisions, poor management, unclear scope, etc. Technical debt is an ingredient that, combined with others, can help things go wrong in the long run. It is like the excess of sugar or salt for our body, we can live with them for a while but if we do not control them in time, the consequences could be terrible.
If you are from the dev team, try to always have the technical debt under your radar and under control. Try to avoid vague implementations that can become quickly in technical debt. Communication is the best tool to tackle it on time.
If you are someone from product, you should know that technical debt is something impossible to avoid because that’s the nature of software development, mixed with business decisions and sometimes with something crueler: time to market.
One response to “First-time shipped implementation is like going into technical debt”
[…] debt, which can slow down development and make it more difficult to maintain the code over time. Technical debt is a term used to describe the costs associated with taking shortcuts or using quick fixes when […]