Understanding Technical Debt in product delivery
There is a saying in English for financial debts by Earl Wilson: "There are three kinds of people: the haves, the have-nots, and the have-not-paid-for-what-they-have."
He is describing people who had all the things they wanted but were not ready to pay for them.
Let me tell you a story...
One of my friends was a big fan of buying new gadgets when they came out. I could not remember even once when something was launched, and in a couple of weeks, I did not see it belong to him. He was earning quite well in his job. Obviously, he had multiple credit cards to pay for all the stuff he bought. He used to use them as time opportunities, as banks always have some offers to get people to buy new things. The same thing goes on for months. When he gets his salary, all the money that used to go into paying these bills disappears. In one unfortunate month, he could not make full payments and had been asked to take the minimum payment option and pay interest over it. There came a time when his interest amount was way more than what he had borrowed from those credit cards. His financial plan crashed, he did not have any cash, and he had to sell his precious gadget collection to free himself from it all at once.
Debt, which could be financial or technical, is not a very great thing to have, especially when you are going through tough times, Technical debt has been a buzzword now when it comes to product delivery.
What is technical debt?
Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project that later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. Well, to explain in layman's language, making coding or design decisions that are suboptimal—or that we know will need to be addressed and updated in the future—in order to get what we want or need into production sooner.
Reasons which lead to technical debt
1. Over-dependence
Technical debt is the result of the design or implementation decisions you make and how those decisions age over time if they aren’t incrementally adjusted or improved. The longer you hold fast to those designs and implementations without incremental adjustments or improvements, the larger the debt, or effort, becomes to make those needed changes. If you have some modules designed with very tight coupling, meaning it is almost impossible to change one without making certain changes in the other, then there is a huge chance you might have to revisit the code and refactor it.
2. A sudden shift in requirements
Even full-featured applications completed on time may arrive in the marketplace already out of date. You have designed the architecture as per the previous specifications, and when suddenly major components are requested to change in the middle, it creates a ripple effect, and you have to revisit the code and refactor it again.
3. Putting quick fixes in place
This is quite a common reason why a team accumulates technical debt for not meeting deadlines. Developers create temporary solutions with the intention of having them perfected in the next sprint. It is often the result of using quick fixes and patches rather than full-scale solutions.
4. Later, discovered a better way
When you try to put business requirements into the logic, there are multiple ways to do it in the same programming language. Languages like Python have provided separate directories to get the functional requirements fulfilled. When we are unaware of such optimized solutions, we tend to do everything with known resources, which limits our capacity to write clean code.
5. Newer versions
Developing modern applications typically involves several coding languages, developer frameworks, and libraries, which can become obsolete or not supported each year. Today's Python could be tomorrow's Visual Basic. Java introduced functional programming dynamics in its 1.8 release, which is mainly used to focus on concise code and reduce unnecessary complexity. Rapid updates in the version of programming languages we are using could be the reason we might have to look into our code repositories.
6. Defects
Defects reduce creative thinking as fixing them and deploying them as soon as possible would be the first thing on mind. The defects in the system can cause major blunders. The person who wrote the code originally may not be the same person who has been assigned the defect of the same functionality. So, as per the understanding of the new resource, he tries to make changes, making sure to not break anything.
Effects of technical debt:
Technical debt can have a significant impact on products and businesses as follows:
1. product bugs that lead to performance issues.
2. Extended-release cycles and market time
3. Concerns about code quality
4. A decrease in team agility and productivity
5. Poor user experience
6. A higher overall cost of ownership
7. Breachable cybersecurity flaws
8. Difficulties with scaling and adopting new technologies:
How to avoid technical debt?
To be very honest, no one can avoid it totally, but we can have some preventive measures to deal with and mitigate the risk it creates, as follows:
1. Establish a code review culture.
2. Schedule a separate team meeting.
3. Ongoing Code Refactoring
4. Adoption of Agile Methods to deal with technical debt.
The longer it takes to pay off technical debt, the more interest and costs accumulate, so it is always preferred to have a plan and practice while dealing with it as follows:
1. Establish metrics for measuring technical debt.
2. If you are following agile already, make sure you communicate about technical debt with your product owner and make them aware of the effects it could have on a product if not addressed properly.
3. If you are dealing with a lot of technical debt, then assign separate resources to get rid of it.
4. Develop automated tests
Conclusion:
Technical debt is not inherently bad. Most development teams cannot avoid occasional tradeoffs between speed, cost, and quality. Technical debt only becomes a concern when you do not know about the debt and ignore the alleged debt.
Comments
Post a Comment