The software industry is a volatile world. Technologies trending today will be outdated in the near future. When the .NET Framework was released in the early 90s, developers were crazy about learning this new technology. But cut to 2010, no one was keen on learning this framework. It’s because its days of glory were long over. Objective C & Perl are also following the same roadmap & we won’t be surprised to see these languages completely out of production soon.
Machine Learning, Deep Learning, Blockchain, AR/VR right now are the hottest concepts in the market but we don’t know if 20 years down the road, we still will be working with these technologies or not.
In short, as time progresses and new technologies arrive in the market, the old programs are labelled outdated and their demand & support tremendously decreases. In this writeup, we will be discussing the concept of ‘Technical Debt’ & we will also have a look at how changing technologies have an impact on ‘Technical Debt’.
We all have taken loans from the banks, right? When you take a loan from the bank, the bank charges you a certain interest & you have to repay the sum of the original amount and the interest to the bank. Therefore, it can also be said that you are officially in ‘debt’ i.e. you owe money to someone. The longer it takes you to close your loan, the worse it gets.
The case is the same with ‘Technical Debt’ as well. Technical Debt is a programming concept that originated from making ‘Quick & Dirty’ development decisions. The overall result is that there is now an overhead cost involved in reworking the code, that is now not working up to the expectations, because of taking the shorter route. But, is debt a bad thing? It certainly depends upon the situation & how you use it. Stay tuned as we read more about ‘Technical Debt’.
Technical Debt Quadrants
13 Different Types Of Technical Debt
Everything has a reason. Similarly, there is a reason behind Technical Debt as well. While Technical Debt now has become a recurring event in the life of Software Developers, it is important to know the reasons behind it.
The following are some of the main reasons behind this concept
1. Time Constraints:
Software Developers are always working with tight deadlines. Call it the overpromise by the management or the laziness on the part of the developers, it is a true thing that Software Developers are always under pressure to meet the deadlines. With such a scarcity of time, it's reasonable that developers are looking forward to making the code work than anything else. Therefore, they often forget to keep track of concepts like Time & Space Complexity, Code Quality, and Scalability. Therefore, at present, the code works perfectly fine but as time progresses, the client sees a lot of bugs in the program & might also notice that the speed is not what he/she expected. This leads to a situation of Technical Debt.
2. Miscommunication & Business Decisions without consulting the Development Team:
As surprising as this may sound, this is actually one of the major reasons behind the concept of Technical Debt. Most of the clients are non-technical in nature & while making the requirements, they cannot distinguish if the feature is implementable or not. Also, the question is whether the feature is really required or not. This often creates miscommunication between the development team, the managers & the clients. This leads to the random implementation of features & if the client is not satisfied, a redo is assigned in the case.
3. Lack of Future Planning:
Let us suppose a Software Team is building a SaaS Product. Initially, they thought that their servers would receive 1000 requests/hr. Therefore, they implemented the concepts in such a way that their server could handle 1000 requests + some overhead/hr. But, suddenly their product gained popularity & now there is an inflow of 100000 requests/hour. The software developers are therefore unable to manage the requests as they have not thought about the scalability factor. This would require them to rework their code again & hence a situation of technical debt arises.
4. Changing Programming Languages:
As mentioned in the first paragraph, changing programming languages also play an important role in the concept of ‘Technical Debt’. Though it is a long term effect, it surely contributes to this concept. A new software written in some very unpopular & old programming language would surely need to be reworked in the coming times.
5. Lack of Coding Standards & development by Junior Devs:
Big companies care a lot about coding standards. Startups, not so much. The end result, the code becomes messier and messier & at one point in time, it becomes problematic to debug & add new features in the code. Similarly, Junior Devs & recent graduates need to be trained on Coding Standards & Code Quality, otherwise, the code might be messy & it will become difficult for future devs to understand the code. In either way, a situation of technical debt is created.
Once, we have identified the reasons behind Technical Debt it is now important to understand how we can reduce the debt. We mentioned some of these, however, we won't be describing them in detail. Some of them are suggested below.
How We Can Reduce The Technical Debt
- Recurring Code Reviews
- Choosing a Flexible Architecture
- Proper Testing (Automation Preferred)
- Keeping a record of the changes We hope you have now understood what technical debt is & why it is important for software teams to successfully negate it. We also hope you would follow the above-mentioned suggestions to reduce the technical debt.
4 Most Interesting Facts About Technical Debt
Top comments (3)
All true but .Net is still very much alive and well. Including it as a legacy architecture shows a technical debt bias and lack of understanding of what .Net is today.
It's the very reason managers and architects make bad decisions from the start and contribute to the problem out of the gate.
It's confusing how the frameworks are being named: NET Framework, NET Core and now NET. Maybe NET Framework can be considered out of date?
I could only see myself using NET Framework for Windows OS specific applications such as P/Invoke or WPF (not sure what the cross platform status of WPF is). Otherwise, you can develop applications for any platform using NET Core and NET.
At my current company, we have applications written in NET Framework (WinForms and ASP.NET), NET Core (AWS Lambda, ECS Tasks) and NET (ASP CORE on AWS EC2). And it's the NET Framework applications that are holding us back, since they are not compatible with the newer library types (Cannot add a NET or NET Core project as a dependency to a NET Framework project). I could write a shared library using NET Standard to target both projects, but that introduces a new problems...
problems
In this case, you need to install any NuGet package that a NET Standard references into the other projects, otherwise they will not be copied over on build. Plus if a project already uses a NuGet package but a different version, the problem becomes more complex with assembly version resolution
At that point, I would rather re-code everything to no longer use NET Framework, because anything I could do with it, I could do with NET Core or NET. Eventually, I just hope everything is just NET and the rest dies.
Based on that, I would say that NET is not legacy, but NET Framework might be legacy and potentially not a good choice depending on what you are doing with it. The current ecosystem is very confusing >.<
I'm curious, but where is the data source for that statistic that says by 2024 global tech debt that has not been fixed will cost 4 trillion?