How Frontend Devs Can Take Technical Debt out of Code

Technical debt can take a variety of forms. It can look like bugs left in coding or coding practices that vary by developer within the same department.

Technical debt is anything that can cause additional work or rework because it wasn’t done right the first time. Sometimes developers write code that functions extremely well on one machine, but when it’s deployed into a distributed environment, it fails — that’s also part of technical debt, said Shashank Purighalla, a former web developer who is now founder and CEO of BOS Framework, a cloud infrastructure and DevOps automation platform.

“At a very high level, the business level, you can talk about intentional technical debt, which almost every programmer [and] every dev team takes on because of time constraints, budgetary constraints,” Purighalla said. “There’s also a lot of unintentional or unintended technical debt, which people just do not know that they’re taking on — because of lack of knowledge, because of limitations in terms of their awareness of the overall ecosystem, because of some sort of a siloed view.”

Frontend and web application developers can help resolve technical debt, Purighalla told The New Stack. But first, they have to know what technical debt looks like.

Understanding Technical Debt

Developers can identify technical debt in a variety of ways, starting with that most annoying of technical debts: Fixing bugs in the code. But there are other indicators, he said.

“A senior developer, in many cases, is capable of looking at code and saying, ‘I see certain constructs that have been poorly done, or there are certain implementations that may be suboptimal,’” Purighalla said. “Any[thing] from identifying bugs in the system, to unfinished code, to poor implementations, and — rising up a little bit to the ecosystem analysis — security constructs that are missing or certain protocols that are not done properly.”

Evidence of software technical debt can be seen in the rise of cyberattacks over the past three years, he said.

“This is a consequence of technical debt, and I call it unintentional technical debt in many cases, because the technical team that’s working [on it] or has introduced it or has taken over that program is not even aware that there are all of those problems,” he said.

Think Full Stack, Act Frontend

To combat technical debt, developers — even frontend developers — must see their work as a part of a greater whole, rather than in isolation, Purighalla advised.

“It is important for developers to think about what they are programming as a part of a larger system, rather than just that particular part,” he said. “There’s an engineering principle, ‘Excessive focus on perfection of art compromises the integrity of the whole.’”

That means developers have to think like full-stack developers, even if they’re not actually full-stack developers. For the frontend, that specifically means understanding the data that underlies your site or web application, Purighalla explained.

“The system starts with obviously the frontend, which end users touch and feel, and interface with the application through, and then that talks to maybe an orchestration layer of some sort, of APIs, which then talks to a backend infrastructure, which then talks to maybe a database,” he said. “That orchestration and the frontend has to be done very, very carefully.”

Frontend developers should take responsibility for the data their applications rely on, he said. For instance, frontend developers should be aware that there are roughly five types of data that developers ultimately present or capture from the interface:

• Confidential data;
• Highly confidential data;
• Restricted data;
• Internal data; or
• Public data.

These five types of data have different requirements, based on how it’s being captured and then put back into the database or, conversely, how it’s being fetched from a database and presented in the interface, he said.

“The types of interfaces are also very important when we talk of frontend web applications,” he said. “Today, especially in the AI world, you’re not just talking of data being slapped on a screen or painted on a screen. You’re talking of a highly interactive system that could be natural language processing driven. So based on that, how it is being captured is very, very important.”

For instance, frontend developers need to know when to use encryption, a CAPTCHA, or a registration form.

“It’s important to understand that there’s also a lot of liability today that goes into development,” he added. “What developers do not understand directly is how their decisions could impact the organization and their leadership in many, many cases.”

Standards for All Developers

To start reducing technical debt, development teams should adopt coding standards with which every developer complies, he added.

“At a very basic minimum, you’re thinking about nomenclature,” Purighalla said. “How are variables being declared and how are they being named? Public variables, global variables, private variables.”

Development teams also should adopt test-driven development, he advised. In test-driven development, unit test cases are created before developing the actual code.

“At a very minimum, test-driven development is a very good strategy to reduce the number of obvious bugs in the functionality and the user usability itself,” he said. “So requirements are viewed not as a checkbox that has to be checked off, but as a part of an outcome that has to be achieved.”

Test-driven development creates a mind shift that supports thinking about code from a functional code integrity or code completeness standpoint, he added.

The frontend also has to think about whether the web applications are being developed for some internal purpose or as a SaaS application for public consumption, he added. There may be compliance concerns around HIPAA, SOC 2 or other regulations, he added. That combined with concerns about data and security should guide developers.

“Those determine the types of standards that have to be followed, certain basic principles in terms of code scans, code coverage, and security scans [that] must be done at a certain periodicity,” he said. “Either this is a static code analysis that’s done, or it is done in every single deploy cycle.”

Good practices must be geared toward ensuring readability, he added, and there must be proper, in-line documentation. That could be as simple as developers adding comments about who is developing it, when is it being written, why is it being written, what requirements exist, and what is the purpose, he said. Comments should also indicate whether there is a deeper design document or sequence diagram of some sort reference in the project.

“The absence of this is why we have the number of cyber breaches — I cannot over-emphasize that,” he said. “It’s so easy if you have the choice of tech stack sometimes, right? If you were to go with the frontend, with just an interpreted language versus a compiled language, let’s say PHP, it’s so easy to find your way through and then start hacking a system. It doesn’t take very long, even if there’s a small vulnerability. If you were to go with a basic compiled piece of tech, the chances of somebody doing that, if it’s done well, are lowered greatly.”

In addition, developers across the organization should all follow the same standards for these practices, he added.

“Developers must understand that they’re a part of a larger ecosystem, and building a piece that works in the overall picture,” he said. “Understanding everything from the business viewpoint, and then working backward for that business outcome, which could include certain security constructs I would not program for.