Technical Debt
Originally posted in efficientuser.com
Sometimes you might have come across the word Over-Engineering. The good programmer does that intentionally to avoid the technical debt.
Technical debt 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.
Boxing yourself with bad code.
Technical debt keeps on raising when you are boxing with the bad codebase. The main reason of technical debt is — we are attempting to solve a particular problem in our software with some shortcuts or some quick fix.
Refactoring is the key.
Boxing with bad code will end up making the code base complex to do further changes or maintenance. Refactoring the code from time to time will help to make the code more adaptive.
Quick Fix — No longer works
When we are doing a quick fix to any problem, we should aware that we have to accept the technical debt we are making. Doing similar stuff regularly will end up the codebase into the worst place to visit.
At some point, your code does not allow you to change anything. And you will break something when you attempt to create something or change something.
The increase in technical debt in the software will make the system more fragile. If you attempt to make any crucial fix which urgently needed, you can’t do that without breaking something. That’s the cost we will be paying as an interest to the debt we were created from the beginning time.
The common mistakes which lead to increase the technical debt
- Urging into deadline without creating core components
- Delivering MVP (Minimum Viable Product)
- Working for Now moment
- Bringing unaccomplished POC (Proof of Concept) into production
Hard Coding
You started killing your code when you started Hard-Coding.
It might sound crazy, hard-coding will make you do multiple iterations when you are an attempt to change something in the software.
Let's consider you have a warning message throughout the application as “This request has been submitted successfully”. And you have used it throughout the application in multiple places.
Suddenly, we need to change all the occurrences of warning messages into something else. Let's say — “submitted successfully to the server.”
Since it is a simple text, you have hard-coded throughout the application. And also you have decided that it is going to straight-forward when it needs a change.
Actually it isn’t. So, what would be the approach here? How you will be doing the text change in 100 places in your application?
- Find and replace?
- Regex to match the text and replace it?
- Or by using some magic refactor tool?
Most of the above best cases would have failed if the text is split into two lines or didn’t catch during the search. Earlier, I had used language translate service in my angular app.
The application would support multiple languages or a variant like US English, UK English, or some other language. So all the text which has been used in the application will be stored in the particular JSON file.
If a Warning message has been used in 100 places in the application, this particular variable in the JSON file would serve as the source for all the messages in the entire application.
If I want to do a text change, I don’t have to worry about much in changing as well as testing. Just think of just a text change would have cost this much time, how about touching core functionalities in the codebase. So avoid hard-coding whenever possible.
Adaptive Code
Don’t do temporary solutions that will work only today and save your application from a current bug that shows up.
Working for a temporary solution will increase the technical debt in the codebase.
Technically debt makes your codebase easily breakable and you have to work harder to achieve even simple results or changes in the software.
Technical debts bring too many bugs which slows down building new features which dependent on existing code.
Think of all the important cases of how the code can change in the future. And Refactor the code if it going to accept the massive change or new feature on top of it.
Most of the time, you can’t justify the codebase needs Refactoring.
Every single time, we will get a question like
It works great, why should touch it? And you can justify your answer all the time.
As an architect or developer, one should think of all possibilities of how the codebase might change in future. One of the possible ways to handle it is the Adaptive Code.
Don’t Fit yourself inside user story
Think of adaptive code instead of just fulfilling or satisfying the current user story.
If your code doesn’t have any future purpose, never worry about it. Just build an adaptive which helps you to improve yourself as well as improve the code base standard.
Earlier, we had discussed the minimalist approaches which will help to build quality code.
Building faster is pointless, when it isn't built right. The art of saying No or YAGNI — “You Aren’t Gonna Need It” is an important skill in the software world. The software should not overflow with the features requested by everyone.
DRY — Instead of duplicating or repeating, just replace with abstraction — function or class
Keep your technical debt down, and deliver the deliverable on time.
We should decide which is an emergency, if there is a bug in production that needs attention and a bug fix. That time we need to accept the debt and handle it in the future. But we should make sure we should not consider a simple text change or minor new feature as technical debt.
Happy Coding!
