Technical Debt: Avoid it at any cost, other wise it would take all your properties.

Here is a fact that I learned from a real life problem, on of my relative took a huge loan from a bank, the risk was totally calculated but its like he is been paying the interest and principle forever, and its a never ending story, Same thing happens to software if you do technical dept. Here is what wikipedia has to say about technical dept.

“Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.”

In short, while doing coding we faced a problem and we do a quick and dirty way to solved it and give a on time delivery. Later you are coming back to the same place again and again to write more dirty code to over come the scenarios its failing.

What a stupid thing to do, if only your higher stakeholders known, that, the two hour job eventually will take huge amount of development time, they would have hired people who would be monitoring so that no technical debt is been introduced in the code base.

if you want to know more about this topic please go to http://en.wikipedia.org/wiki/Technical_debt. There is a significant amount of information is there to help you out.

Suggestions

What to do?

Never ever introduce technical debt.

If a problem takes good amount to time and a significant amount of architectural change talk to your higher authorities, make them understand that this would take time and a quick and dirty solution will lead them more development effort in future.

Take calculated risk

Always follow 80/20 principle if the feature is been used by only 20 % of the users and its unlikely that this would cause any immediate breakdown.  But don’t forget to get back to it quickly and then refactor it, other wise you would soon forget about it.

General Suggestion

• Refactor as you go deep in to the code.
• Try to use design pattern
• Be communicative with the team
• Always follow good process of development (For Example : Agile: Scrum, Kanban)
• Most important try to have some test coverage.

In an ideal development world there is no technical debt, but still there is in real world. so we got handle it correctly, until next time happy coding.