DEV Community

Cover image for Reasons behind bad Softwares (Technical Debts) and Refactoring
Taslim Arif
Taslim Arif

Posted on • Updated on

Reasons behind bad Softwares (Technical Debts) and Refactoring

Bad code haunts everyone sooner or later troubling the one who wrote it along with whole team.

Every developer in the world tries to write good and efficient code. I don't think that there is anyone who writes bad code deliberately.
Then why do we still get bad softwares? Let's look at few reasons for bad code going to production which is generally termed as Technical Debts.

Think of a scenario where you took money from someone on interest, for that time being it solves your problem, right.
But eventually, you have to repay that money to a person with interest. Sometimes, we delay so much in repaying money that the amount of interest gets higher than the actual money which we took from a person which makes it impossible for us to repay the money.

The same is the case with software development, you write bad code, and keep on shipping it to production and since you were not focusing on improving the code, there will be a time when it becomes impossible for you to refactor/improve your code.


Reasons of technical debt

  • Business Pressure

Sometimes business pressure forces us to ship unfinished code to production. To make it work, we do some patches here and there and hides them. But this will come back haunting us.
Don't do this, it is okay to get delayed sometimes instead of shipping bad code to production because in a long time it will cost more money and effort to improve it.

  • Developers not taking technical debts seriously or don't understand the importance of it

This is one of the most common cases, I have seen while working at various companies, many developers don't take these things seriously, for them working code is sufficient.
This becomes almost impossible to refactor and improve the code because your employer does not value it.

  • Lack of Documentation

Documentation is one of the most important aspects of software development. It doesn't matter how good code have you written, if other developers can't understand, contribute or use it. We must write a good documentation explaining every aspect of your code so that others feel, it is easy to use and they don't need to ask you everytime.

  • Incompetence

When the developer doesn’t know how to write decent code.

  • Lack of knowledge sharing among team members

When developers don't share their understanding of project with team members, it becomes almost impossible, specially for junior developers to work on it. They work in dark all the time and eventually create problems for themselve as well for whole team.

  • Lack of tests

The lack of immediate feedback encourages quick, but risky workarounds. In worst cases, these changes are implemented and deployed right into the production without any prior testing. The consequences can be catastrophic. For example, an innocent-looking hotfix might send a weird test email to thousands of customers or even worse, flush or corrupt an entire database.

  • Working in Isolation

This can lead to the accumulation of technical debt, which is then increased when changes are merged. The more changes made in isolation(in your respective branch), the greater the total technical debt because it can cause merge conflict, it is very hard to review it.

  • Lack of compliance monitoring

This happens when everyone working on the project writes code as they see fit. There must be a guideline to follow while writing, documenting, testing and deploying the code.


When to refactor your code

Follow rules of 3 for this.

  1. When you are writing code for the 1st time, just get it done.
  2. When you are doing something similar for the second time, keep refactoring thought in mind but anyways get it done.
  3. when you are doing something similar for the third time, start refactoring it.
  • Adding new feature

While adding new feature into someone else dirty code, first refactor it and then add new features. It is very easy to understand clean code and add new features into it.

  • When fixing bugs

Clean your code, you will automatically find bugs.

  • During code review

This is last and probably the most important part of the refactoring process. After this your code will be going to production. It is always best to do code review in pairs, make sure author is present.


How to refactor

  • Make sure after refactoring your code should be cleaner than previous on and still all features are working. If code is not cleaner, you have just wasted your time.
  • Make sure you have a good understanding of the code you are refactoring.
  • Make sure while refactoring, no new functionality should be added in your code. Refactoring and adding new feature are two different things. Once you complete refactoring, then you can add new features.
  • Make sure all previous test cases are passing after refactoring.

Top comments (2)

Collapse
 
shubhamaryanite profile image
Shubham Kumar Singh

Taslim. Can you please elaborate the point of working in isolation. As while merging, if there are defects - then it can be taken back as we know after merging - which branch is causing problem to the whole application.

Collapse
 
tastaslim profile image
Taslim Arif

Hey Shubham, thanks for the question.
the point of working in isolation means:
In a team, there can 10s or 100s of engineers working and making their respective changes to respective branches, right? Lets say, you are working on a feature which takes 4 weeks and other engineer's work took 2 days , 5 days, 1 week etc. They will be merging their branches to respective CU/sprint push and your branch would be behind multiple commits, all of the sudden you merge your changes and it creates merge conflicts or overwrites the other previous changes, it would become a mess and will take heck lot amount of effort to fix these. You would need to check who made what changes in what branches. Obviously, in a small. team you can manually fix these but. as team size increases, it becomes difficult