I generate Technical Debt, therefore I am

Technical debt exists and probably exists on projects you are working on.

“On a project of mine, you say? This would never happen to me!”. I know, it never happens to us, right? Well… denial is not a river in Egypt!

In my professional life I can think of dozens of examples, but there’s a particular one that I really like to tell you about:

I travelled to a foreign country with the main purpose to discuss some requirements, but the tide changed and the meeting ended up with the customer saying something like “we need to see the app working or it will be pretty impossible to follow up with the deal”.

I went back to the hotel and spent a couple of days developing a proof of concept due to lack of resources on the HQ. Showcased the app to the customer and things got back on track. The main purpose was achieved but the PoC was poorly coded.

Back in the HQ, when I debriefed and handed over, someone decided to start working on top of my single project PoC. A couple of months later, the project was unmaintainable due to things like tightly-coupled components, lack of configuration files and lack of tests, specially because no one wanted to take the ownership of doing it properly. It was no surprise but it was a pain to put it back on track.

This is just an example on how easy it is to generate technical debt. Just like any other kind of debt, uncontrolled technical debt becomes a giant snowball that will eat you up.

It’s easy to feel lost when you (re)inherit a project swamped in technical debt and that’s already delayed. The silver lining is the set of learned lessons that you take for the next endeavors. Documenting all things is one of those lessons. Another one is to always use a static code analysis tool.

The good part of the modern world is that is never too late to mend one’s ways. Tools like Codacy help your team to enforce best practices, address security issues and reducing technical debt… Even when you start with 755 issues 🤠.