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…
View original post 149 more words
