Technical Debt

Technical debt was never ever meant to give you permission to write shitty code.

Let me tell you a story about technical debt.

Once upon a time there were these men and women who were tired of waterfall literally causing projects to lapse, limp, fall behind schedule, go over budget, and fail.

They came up with this radical idea that you can begin writing code day one.

Architects went nuts, "You can't write any code until the architecture is signed off on!"

Analysts went nuts, "You can't write any code until the analysis and design are signed off on!"

These brilliant men and women were not deterred!

If we write a failing test, write just enough production code to get it to pass, then refactor; we really would be able to put new knowledge into the code as we learn more about the problem and solution domains.

I may be taking a whole lot of artistic license with this story.

At one point one of the brilliant men, Ward Cunningham, coined the term technical debt.

Technical debt gives you permission to write code before 6 months and a sign off of architecture; before 6 months and a sign off of analysis and design.

We'll use TDD so we know the code is tested and maintainable. We'll even grab a colleague and have him or her help us write the code.

Technical debt is a knowledge gap between what you know at this moment writing clean code TDD, and what you'll learn in the future about the domain.

You can safely go back and add the new knowledge because you crafted your code.

I know, I know, it's too late. Poor Ward's term has been hijacked and used as some sort of way to track and measure shitty code because we all know you'll go back and fix it someday.

Is it someday yet?

Here's a thought.

Don't write shitty code.