DEV Community

Cover image for Why we still have tech-debt?
Amartya Jha
Amartya Jha

Posted on

Why we still have tech-debt?

When a developer creates a pull request, the reviewer checks it for business logic. However, what often gets overlooked are:

  • Data structure optimization
  • Code security checks
  • Function complexity and reusability
  • Cleaning up dead and duplicate pieces

Let's break it down and understand all 3 stages.

Stage 1 - Development Editor:

We all add linters; they detect issues related to formatting and some anti-patterns. As developers, we see numerous issues, and even some paid linters stack rank the issues based on severity. However, it fails in multiple aspects because developers don't have time to manually fix these issues. Developers want these issues to be auto-fixed, or else they will silence them. Secondly, these static linters lack context about your codebase, so they may not effectively prioritize high-severity, high-impact issues for you.

Stage 2 - Git Hook (Maybe):

Some organizations have Git hooks in place to prevent certain bad practices from being pushed. The problem here lies in the depth of the rules, as most rules focus on high-level, framework-specific checks. You can think of these as extensions of your linters, with the added capability that you can't push the code if certain rules are not followed.

Stage 3 - Pull Requests (PRs):

Now, you have pushed your changes and created a PR, waiting for the reviewer to merge it. Here, the challenge is that the reviewer also has 10 other PRs to review, so they primarily check for the correctness of the business logic. Having reviewed over 1000 PRs, what I've learned is that no reviewer can ever have 100% context of their codebase. Therefore, we trust that the developer has followed all the checks, fixed anti-patterns, dead and duplicate code, ensured the use of correct data structures, etc. Additionally, awareness of security and compliance issues is not always present with most developers, so we don't review those aspects. Moreover, both the reviewer and developer are under pressure to ship the product faster, with the end goal being deployment in lower environments. If something breaks, we will fix it there.

The reality is that nothing will break because the existing checks primarily focus on unit or end-to-end tests for business logic, which are already reviewed. Consequently, "bad" code gets checked in and committed.

This situation results in technical debt. Why haven't we been able to solve it until now? It's due to a lack of enforcement that doesn't slow down developer velocity.

What do we need then?
We need tools that have a great context of the codebase, prioritize high-severity, high-impact issues, and suggest auto-fixing of these issues without breaking any existing logic. The tool should also seamlessly integrate with the developer journey starting from IDEs to PR checkers.

We are building CodeAnt AI (YC W24) on the same lines, and it is live; feel free to check it out here.

Billboard image

Use Playwright to test. Use Playwright to monitor.

Join Vercel, CrowdStrike, and thousands of other teams that run end-to-end monitors on Checkly's programmable monitoring platform.

Get started now!

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs

👋 Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay