I recently worked for a company that had technical debt as a strategy to cover the make it to the first release, scheduled at 6 months into development.
What unfolded was what any article/presentation on technical debt warn you about. Lack of predictability. The main issue with technical debt is that it creates invisible problems. They are not factored in the project plan but will slow down work. A task that you estimated to 2 hours as it is what it takes you in normal circumstances end up taking 2 days. Initially, you address it by working a few extra hours every day. However, unless you take the time to do proper refactoring, the overhead progressively grows. Soon, there is not enough hours in a day to make up for the time lost dealing with the debt.
Your best option. Accept that there is a problem and address it. Second best, leave before it has too much unwanted impact on your health or reputation as a professional programmer.
To quote the great book, Clean Code: "[...] it is unprofessional for programmers to bend to the will of managers who don't understand the risk of making messes".
Some presentations on slideshare:
- 7 Steps to Pay Down the Interest on Your IT Technical Debt
- Identifying and Managing Technical Debt
- Technical Debt
- Managing Technical Debt by Ted Theodoropoulos
- Technical Debt from metaphor to theory and practice by Philippe Kruchten