If you’ve been a developer for any significant amount of time, you’ve run across the concept of “Technical Debt.”

Technical Debt is nothing more than the eventual consequence of every design decision you’ve put into a codebase.

At the end of the day, we all have to ship our projects; we all have to deliver a product.

Technical debt represents the amount of work, at any given point in the project plan, to finish your project, and make it deliverable.

If we’ve made poor refactoring practices part of our design process, if we have paid too little attention to infrastructure design, if we have made a bet – a poor bet – on a software tool, or a software language, or a software platform – all that goes into building up your technical debt.

Now, when you look at large scale projects that have failed (when they don’t fail for lack of vision, or lack of project management), the next most visible cause is trying to pay down too much technical debt at any given time.

So, when you see a version going from 1.0 to 2.0 to 3.0, typically what is happening during those transition periods is the paying down of technical debt; refactoring modules, redesigning software, redeploying platforms.

Technical debt can be manageable, when taken in small bites.

In order to minimize the impact of technical debt on your project, you need to have good testing practices, you need to have good design practices, you need to have good infrastructure practices, and you need to have good refactoring practices in place.

It’s an ongoing process. You don’t incur all of your technical debt overnight, all in one fell swoop – and you shouldn’t expect to pay technical debt all at one time.

Go, and be you.