It’s been a while now since I wanted to write a blog post about this topic, but recently I stumbled upon this Hacker News thread and felt that this was the right time to do it because as an engineer myself, I find it disturbing seeing fellow engineers having such an attitude in general.

And I couldn’t resonate more with one of the comments in this thread saying among others:

Also, respect the team. Maybe they aren't doing what you would, but they are keeping this beast alive, and probably have invaluable knowledge of how to do so. Don't come in pushing for change... come in embracing that this beast of a codebase makes 20 million a year. So talk about how the team can improve it, and modernize their skills at the same time.

Because if you walk in, saying, "This all sucks, and so do you, lets throw it out", do you really have to wonder why you are hitting resistance?

So, here is my story…

Back in the day, I once joined an early-stage startup. To be more specific, I was the fifth member of the team, but at the same time the first frontend engineer.

We started building a checkout form that would integrate with various eCommerce platforms, aiming to help shoppers complete their purchases much easier compared to the existing checkout solutions out there.

At that time, I had no prior experience in this domain, and when it came to picking the technology stack for the front-facing app of our product, there was no clear vision as to what would be the target state of it. Meaning that I was completely unaware of possible challenges or roadblocks that would come along the way.

My decision then was to start lean and see how it goes. I tried to be minimal, and avoid premature optimizations as much as possible.

After one year of working on this product, and having expanded the frontend chapter with more teammates, we started facing various issues. First of all, the lack of a specific framework that would provide its own guidelines, best practices, and documentation, made it difficult for new members to get onboarded as smoothly as I’d like.

So far, our own conventions had been laid, which apparently were harder than expected to be followed by everyone on the team. Especially from those teammates, that to keep up with the consistency of the codebase was not among their best skills.

That is a very tricky situation to be in as a team leader because you might start doubting whether you are qualified to be in this position and sometimes is hard to accept and objectively identify any bad decisions that have been taken.

On the other hand, the app was working, shoppers would successfully complete their orders through our product, and in general, you wouldn’t say that anything was broken.

There was just a lack of confidence after a specific point of how this would scale moving forward adding more and more features in it.

Which brings me to my general point… What’s wrong with technical debt?

This state we had reached, was definitely expected from the very first time this codebase was created. When we started building on it we knew it was about an MVP that would validate our startup’s early requirements which most of them were just assumptions.

I don’t think anyone would have expected at this point that our product would be as robust and scalable as if we were an established company with a big engineering department that had the luxury of time to refactor things as they go.

So this is why I find it counterproductive, to have to defend and explain to others why an almost-a-year product is not in perfect shape.

As engineers, it should be our duty to find the right balance between having a state-of-the-art codebase with cutting-edge tech stack and also having a product that works and serves its purpose based on the business requirements.

Beyond that, let’s face the reality here that any technology -especially in the frontend world- might have been abandoned by the community or even deprecated in a few months or years from the moment we decided to adopt it. It is what it is and after a decade in this field, I am fine with that.

So, there’s nothing wrong with technical debt. Instead, from a personal point of view, whenever I come against such situations I find it challenging to understand what is the product doing, what were the foundations or patterns that were followed while this piece of code was developed, and then it is where the interesting part is coming, when I try to shape an attack plan on my mind, tackle the issues I face with it, and find out what is the right solution so that my contribution would help it scale based on the ever-evolving product requirements.