Copy of Thoughts over ? : Tech debt is just bad code?

?? Hi, this is Navjot with a new newsletter. I write about software engineering, best practices, industry standards, and career growth. Thank you for being a reader, and making it a family of over 1000 frequent readers with over 200k views.?? ??        

What's "Thoughts over ?"

Thoughts over ? is a segment where I will be discussing "non-technical" problems that software engineers and Technical Project Managers have to deal with regularly.

In this article, I thought of talking about "Tech Debt" which is a frequent phenomenon that haunts engineers and SWE Managers over short deadlines.

Tech Debt: An Overview

Tech debt is unavoidable in the real world.

Compromises are necessary for the business to grow and these compromises pile up as debt. It's always necessary to keep the debt cleaned up in time to ensure the expense is under control.

Mostly people believe tech debt is just bad code. It’s like saying that the previous developer did not do the job correctly and my genius will fix it all. ??

In my truest opinion, this statement is wrong and I will discuss why.

Definition

What is technical debt? In popular opinion, we term it as

"Difference between what was promised and what was delivered?"

but a more appropriate definition would

“Technical debt – or code debt – is the consequence of software development decisions that result in prioritizing speed or release over the well-designed code. It is often the result of using quick fixes and patches rather than full-scale solutions”.

This can be too formal for many of us so let's put things into perspective.

Perspective of tech-debt

Imagine that you have a project in front of you and you can develop it in two potential ways. One is quick and easy but will require modification in the future. The other comes with a better design but will take more time to implement.

Releasing code fast and iterating later?

Releasing code faster and iterating over is like taking debt from time. The extra work is pushed for the future and will have to compete with prioritization on any development work which in turn has a very high chance of being deprioritized.

Just like economics, the older the debt the higher the payoffs.

Reckless and Judicious debts

Not all tech-debts are reckless some decisions are made judiciously to prioritize business needs over code perfections. In the end, it's all about managing tradeoffs. Tech debt can be broken down into a quadrant shown below.

?? What are the 4 quadrants of tech-debt

Tech debt is scary

Performance bottlenecks

When we put a lot of patches over the parent codebase the code performs but it brings a lot of flaws that are skipped due to deadlines or other unforeseen issues.

A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. — John Carmack

The tight deadlines and cumbersome development process these teams face also play a key role. Finding, understanding, and fixing these bugs can take a lot of time. And when things are already barely getting done on time, attention to detail and testing are often sacrificed, resulting in even more tech debt, which creates even more bugs.

Lack of documentation in understanding and future-proof fixes

Documentation is really important for software's well-being. A patched and incomplete codebase generally comes with another problem of not being documented completely. If the person who worked on the codebase decides to leave and another person takes over.

New hires face a steep learning curve, making onboarding inefficient.

High development costs

Try putting together a 1000-piece jigsaw puzzle with some pieces missing, some the wrong shape, and the wrong picture on the box. That’s what it’s like working on a codebase with unmanaged tech debt.

It's painful to work on and see multiple problems piled up that could have been easily avoided with a better plan in mind. Developers will spend countless hours fixing inconsistencies and bugs and creating some if not many during the whole process of refactoring.

Being safer than sorry

Tech debt can haunt you at any moment, and here is a small list for you to make sure you avoid tech debt as much as possible

• Find a measure to identify “code quality”
• Run integration and load tests frequently to identify problems and bottlenecks
• The main branch should always be ready to ship and should have updated and bug-free packages
• Document code issues as notes whenever possible keep adding priority to small inconsistencies and bring them up in engineering calls.
• Maintain a central documentation and readme practices for others to understand as well.

Tech debt cannot be eliminated by individual efforts. It needs collaboration and efforts from everyone to keep the codebase happy healthy and living (Live) :)

Happy Engineering ??