Technical Debt

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:

For more slideshare category on the www.ontechnicaldebt.com website.

Powered by Drupal, an open source content management system