We often make decisions based on short-term requirements or close deadlines with the idea to fix them on the long-term, without acknowledging the problems we are creating by doing so.

What is Technical Debt?

A simple definition by Wikipedia:

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

We can think of the technical debt as group of temporary fixes coming together in a determined project. We’ve all been in a situation where we need to ship a feature as fast as possible but the implementation wouldn’t allow it to be delivered in time. What do we do? We write down a temporary fix and lie say to ourselves: “I’ll come back later and fix this”. Technical debt is not coming back soon enough to eradicate that implementation’s specific issue.

Should I care about it?

The thing about technical debt is that you’re going to have to deal with it whether you like it or not. The sooner you start working on paying-off the debt by refactoring or restructuring your codebase the sooner you’ll be back on agile shipping features and products.

Not working on your technical debt can result in a bunch of issues such as:

• More bugs
• Bad code readability
• Low team’s motivation
• Product delivered out of time
• Product delivered out of budget
• Difficult updates and upgrades on the codebase
• Dragons will eat your flesh while sleeping

Is my team infected?

Yes, every single team has some level of technical debt. However, it doesn’t mean that your team is performing poorly, technical debt can be caused by a variety of reasons, most of them due to human factors rather than tech specialization issues.

It’s your responsibility to accept and assess those issues in order to minimize your team’s technical debt.

What is causing technical debt?

There are many reasons behind technical debt. Some of them are more common than others, and they can vary based on the specific area you’re working on, but the root causes for technical debt are always in the form of the way team members behave during the development stage. There are a lot of causes of technical debt including (but not limited to):

• Bad requirements’ definition
• Delayed code refactoring
• Specification changes
• Chain of command technical knowledge
• Bad communication
• Lame project management
• Team’s motivation to learn

The first four causes are pretty self-explanatory, so I’m going to deepen on the last three issues to get a more clear definition from my own point of view.

Bad communication

It’s well-known that working in teams is complicated. We all have different perspectives, styles and preferences working on a project. Communication is a big issue on every organization, not communicating is as bad as over communicating.

Finding a communication model that enables the team to share their challenges and the way they solved them is a very important issue. Not communicating can lead a team to repetitive code writing, bad dependencies and module design. Also, over-communicating can become a problem as it gets the team on a non-productive state. There should be a balance in communication.

Bad communication is everyone’s responsibility, and should be considered a top priority on every team.

Often, teams use communcation channels like Slack, Discord, Cisco Spark, Workplace by Facebook, Fleep, Jostle, Hive and many others to manage communication more efficiently. I’ve used Slack at most of my workplaces, in college and I can only say that it’s an amazing tool. The catch in here is to try each one until you find one that fits your team’s specific needs.

Lame project management

It is already a complicated subject to talk about, but let’s focus on the specific issues that matter to technical debt.

Handling technical debt from the Project Manager’s point of view is difficult, most of them have no idea of the actual implementation that is going on with their subordinates, in most cases they find out when it’s already too late. Being in charge of a team is not an easy task, handling technical debt should be done proactively during all the development process but most importantly at the early stages of a project.

To be aware of the specifications and being technically able to pass down these requirements to the team is a must and there’s a huge payback in doing so. There should be open communication between the team and the project manager but also being a proactive communicator with the stakeholders and/or the client is a huge opportunity to anticipate and mitigate specification changes. Every change in specification will probably end up as technical debt as the refactor that would be needed to adjust the codebase could be pretty big.

Team’s motivation to learn

This is pretty simple:

If your team is not willing to learn new techniques and improve their skills you’ll end up with technical debt.

The team should be in an always-learning mindset, finding new, innovative and creative ways to design, implement and ship your product. The ability to keep learning and adapting to new tendencies and technologies is what keeps companies afloat while giving people a natural way of professional and personal growth. There will always be something new to learn and, as soon as someone stops learning, the technical debt can become bigger and bigger due to their inability to keep up with new and more elegant, robust and efficient code.

Shipping great products require a great team, and a great team is one which is technically evolving at any given time. As this might create some temporal technical debt, say you learned new stuff you didn’t know 4 weeks ago when you wrote a module, being aware that there are other ways of achieving the same can trigger a refactor and future projects code quality will be greater.

What are the consequences?

The consequences of technical debt can be quite awful. They range from exceeding the budget, exceeding development planned time to the team’s mood while working on projects.

The team

Motivation is a key element for a team’s efficiency. Working twice (or more times) on specific subjects that have already been done can lead the team into more technical debt as the value of their development isn’t considered on the long-term.

Quality standards and better implementations are valid reasons to refactor a piece of code, but explaining them as the benefit that will represent on the development future is sometimes tricky, remember that teams are easily annoyed by not valuing their opinions and views on the implementation. The communication plays a huge role in the adequate understanding of the situation and how the team will feel about the new added work.

The client

As the technical debt push the deadlines away and therefore increases the budget for the development, is pretty clear there’s someone being affected in every single way by this: the client.

Remember that clients get in touch because they want their product right now. They are not going to understand that we took an extra 3 weeks because some poorly-designed module (that we already implemented and/or shipped) need a refactor (They won’t even know what does a refactor means!). Being able to handle technical debt so the client never have to worry about deadlines is done by considering realistic delivery dates and assessing the team’s technical and production-wise capacity.

The product

It is the most damaged one of them all. Although decisions were made that resulted in technical debt, not paying them back in a reasonable time now represents a less agile software development process and a complicated shipping process that relies on more and more temporal hacks just to get things done for the next deadline.

Technical Debt is a direct influence on the updates frequency and creates a non-stable codebase that can become a huge problem for big features and roadmap schedules.

How to overcome Technical Debt

So, yes, technical debt is always going to be there with you. The great news is that you don’t have to bother in eradicating it (as it is impossible) but rather manage it to your benefit.

Communicate properly

Communicating efficiently both with the team and with the client is the most important part of this. Being able to catch up on new standards, libraries, models, languages and tools is a truly valuable skill from your team as well as a realistic roadmap that considers deadlines and refactors that may surely will happen.

TODO, never again

Assuming from the beginning the presence of some technical debt will change the perspective on a project’s management cycle. There will be situations in which some technical debt is necessary to get a specific bug fixed or getting a feature in a specific release, but being aware of its presence enables you with the ability to pave your way towards paying it as soon as possible so you can minimize the need for future refactors.

Just assuming it’s there isn’t enough.

Being aware of the specific modules that carry on technical debt can save you time, effort and headaches during module-dependencies issues.

Conclusion

Technical Debt is often seen as an embarrassing issue to talk about, but, the sooner we accept it and assess it, the sooner we’ll be working towards minimizing it.

There’s nothing better than technical debt as a motivation for a team to keep learning and keep updated in this technological day-changing environment.

My personal experience says that teams that aren’t willing to accept their technical debt are doomed to failure. We should set aside our personal issues and begin working towards creating more creative, competitive and imaginative products.

For comments and feedback, you can find me on Twitter as: @humbertowoody.