Sorry Guys, do not judge me by my writings. I have been in many situations in the past, instead of learning from it i fall into the same pot hole again and again. All in all, software architecture plays a dominant role when building enterprise applications and since i wasn't the architect, i fell into the same pit again.
What is Technical debts
The metaphor "Technical debts" was developed by Ward Cunningham (The man behind wiki) It means design / code / architectural debts that we owe our developments , since we are humans and we want to meet our targets we can bypass some development strategies to make a shortcut, so that we meet the deadlines. Meeting the deadlines doesn't mean we would not re-pay our technical debts (This is one problem that most people/organisations make). We need to go back to the drawing board and re-sharp , this will enable us to learn more on the product and this will strengthen our knowledge of the entire system.
Knowing when to re-pay your debts
You can choose to continue incurring more debts (This will tie you down to the system), or if you are smart enough or at least someone in your team is an anti-hacking developer (A design pattern loyalist) , then you can choose to refactor mercilessly.
Nobody ever said it was going to be easy, but at least you are making the first move to improve your system. Re-paying technical debts is a culture that all software professionals should imbibe. A development team should aggressively encourage this practice , or else none of the team members would come in terms with their weakness or forgotten errors.
I know its good to go faster to the market, but at-least let us look back and re-pay those debts that might come back to hunt us.
What do you think i am doing right now, of course "I am re-paying my debts"
