Sometimes you might have came across the word Over-Engineering. The good programmer do 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 keep on raising when you are boxing with the bad code base. 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 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 technical debt we are making. Doing the similar stuff regularly will end up the code base into a 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 made any crucial fix which urgently needed, you can’t do that without breaking something. That’s the cost we will be paying as interest to the debt we were creating from the beginning time.

The common mistakes which leads 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 to do multiple iteration when you are attempt to change something in the software.

Lets consider, you have a warning message throughout the application as “This request has been submitted successfully”. And you have used it in throughout the application in multiple places.

Suddenly, we need to change all the occurrence of warning message into something else. Lets say – “submitted successfully to server.”

Since it is a simple text, you have hard-coded throughout 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 approach here. How you will be doing the text change in 100 places in your application?

• Find and replace?
• Regex to match text and replace?
• Or by using some magic refactor tool?

Most of the above best cases would have failed if text is split in two lines or didn’t caught during the search. Earlier, I had used language translate service in my angular app.

The application would support multiple language or 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 a 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 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 code base. So avoid hard-coding whenever possible.

Mi Smart Band 4 (Black)

Adaptive Code

Don’t do temporary solutions which will work only today and save your application from current bug which shows up.

Working for a temporary solution will increase the technical debt in code base.

Technically debt makes your code base easily breakable and you have to work harder to achieve even simple results or changes in the software.

Technical debts brings too much bugs which slows down building new features which dependent of existing code.

Think of all the important cases how the code can change in future. And Refactor the code if it going to accept massive change or new feature on top of it.

Most of time, you can’t justify the code base 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 a architect or developer, one should think of the all possibilities how the code base might change in future. The one of the possible way to handle it is 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 a adaptive which help you to improve yourself as well as improve the code base standard.

Earlier, we had discussed about the minimalist approaches which will help to build a quality code.

Building faster is pointless, when it isn’t build 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 emergency, if there is a bug in production which needs attention and a bug fix. That time we need to accept the debt and handle it in future. But we should make sure we should not consider a simple text change or minor new feature as technical debt.

Happy Coding!

To get latest updates you can follow or subscribe! #peace