July 27th, 2019 by Kevin Pimentel

It’s possible that our generations debt crisis has made me more sensitive to technical debt than I should be. As software developers, we are always faced with time constraints and it’s these situations that cause us to introduce technical debt. 

I think a lot of the time technical debt is caused by one of three things: pure laziness, lack of knowledge, or a lack of care. 

Writing code is a form of art. Our readers, or consumers, are other fellow software developers. Because of this, it’s very important to implement things as best as possible. No developer wants to work with developers who make their life more difficult than it should be. It’s important to demand some level of professionalism from fellow developers. 

I’m not saying code has to be perfect but there are obvious times when you are dealing with code that just isn’t meeting any sort of standard. I want to touch on a few real examples that I have come across. These examples illustrate each of the technical debt causes that are at the root of all bad code. First, we should talk about what technical debt is.

What is technical debt?

Technical debt occurs when you choose the “easy way” or the “fast way” of doing something, instead of spending the extra time and effort on a more appropriate long term solution. We’ve all been told to just make it work. Just do xyz, no one will know. And It’s true, the client will not know. But we, the developers, always end up being the ones that suffer the consequences.

I have seen developers burn out over lack of coding structure. It always starts when a programmer becomes distant, and eventually toxic to the team. This leads to high churn rates which is extremely negative for teams. 

When you spend time and resources training developers that leave it’s a huge loss for the company and team. You’re losing an asset and an unquantifiable amount of knowledge.

When technical debt builds up, developers get fed up, they get burnt out, they eventually become toxic, then they get lazy and stop caring, and eventually they leave.

Lack of Knowledge

This is probably the only time when introducing a quick fix is acceptable. As long as you plan on revisiting this type of technical debt, I have no problem with it. A good example of this kind of situation is when a bug is found in a legacy application that you don’t know much about. In order to implement a quick workaround you hard-code xyz and get it working.

I think this is acceptable for a limited amount of time, especially in fast paced work environments.

Pure Laziness

Lack of knowledge can quickly become the bad kind of laziness when the quick-fix is not revisited, and rots over time. It’s important to be the kind of lazy developer that wants to automate everything to avoid doing a task more than once, but that’s not the kind of developer that I am talking about. 

The kind of lazy that I am referring to is the kind that has a history of hard coding, commenting / uncommenting code based on data, copying pasting code because it works, and so on.

Recently, I was dealing with a legacy application that centered a video on a page depending on the number of videos. If there was a video alone in a row it needed to be centered. I discovered that a developer was updating the centering code by commenting or removing comments from a piece of code based on the amount of videos in the database. 

He was actively showing or hiding the bootstrap offset class based on the video count. This type of laziness is remarkably infuriating. Think about this:

Every time a client updates their videos the code will need to be changed. 

Now let's say the client updates the videos once a month. The client will have to contact development every time it doesn’t look right. Let's be generous and say that this can all be accomplished in 15 minutes each time. Let's say this goes on for a year, that’s an hour every four months, 3 hours a year. 

He's wasting 3 hours a year, when he could have taken 15 minutes to implement a:

videos_count % 3 === 1 

And called it a day for the rest of humanity. This is the type of thing that makes me want to choke a baby llama.

Lack of Caring

Lack of caring is easy to detect in the code. It’s usually a bunch of copy and pasted variables that make no sense, and changes that have to be implemented in 15 different places.

When a developer stops caring his code becomes very toxic and it’s extremely hard to follow what is going on. You never want to work with a developer that doesn’t care, this is the worst kind of developer and they will make your life more difficult. 

Whenever I get involved in the interview process, I am looking for what kind of effort this developer puts into their code. This will tell you a lot about the type of person they are. You want to keep developers that don’t care about code, and only care about it “working”, as far away from your team as possible. These types of developers will destroy your team and make everyone frustrated in the process.


The best way to deal with technical debt, in my opinion, is to get everyone to buy in and own the code.

When you feel that you own something and are invested in it, you naturally want to do a better job. The second thing is to implement a coding standard. A coding standard should be such that you can’t tell the difference in who authored a line of code. 

The final thing is code reviews. If you lack the knowledge to implement a fix, having fellow developers looking at the code might trigger the feedback needed to improve the code. Also, when you know other people are going to look at your code you tend to do a better job. 

If the code is still a dumpster fire, you can always reject it. Which is why we version control.

Kevin Pimentel

There are two types of people in the world: those that code, and those that don’t. I said that! Quote me. My name is Kevin and I’m one of the ones that codes.