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 then fail.

I would get tired of that too.

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 achitecture 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 deterged!

One said, "With sufficient testing, we could refactor and add new knowledge as we gain it."

"Refactor?! What are you talking about?"

"Hang right here, I'll go write a book and be right back."

A few others put their heads together and said, "If you write tests first, don't write any production code until there's a failing test, and 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 or may not be taking a whole lot of artistic license with this story.

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

What technical debt does is give 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. Two brains are better than one right?"

As my good friend Geepaw likes to say, "the keyboard is not the bottleneck."

I digress. I'll tackle pair and mob programming later.

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.