The Top 3 Reasons to Remove Bloated Code

Many things can slow down the development and deployment of a project. But one of the most significant issues is also wholly manageable: Code Bloat. Bloated code occurs where the runtime environment contains useless pieces of code, like libraries or service binaries, that will invariably lead to software inefficiencies and security vulnerabilities. It is typically caused by inadequacies in the language in which the code is written, the compiler used to compile the code, or even a feature-focused programmer who writes more lines of code than required for the application to work.

Of course, most programmers will insist that their code is clean, so how does code bloat even happen, and how does it differ from tech debt?

Bloated code in the runtime environment is one of the most common tech debt issues. At the beginning of the development process, you start with an image that “seems fine for our current needs,” then install whatever it takes to make everything work without ever removing any of the installation components or reducing the base image contents. By continuously adding features and functionality without going back and eliminating unused components, you get tech debt that accumulates over the life of the image. The use of open-source libraries amplifies this problem because developers will pull entire libraries into the image and only actually use a fraction of the functionality. The remaining 80+% of the library becomes bloated code.

Because many teams find themselves in a ceaseless development cycle, it’s easy to overlook bloated code until later in the process. Then, when it comes time to test the application, all the flags go up, adding otherwise unwarranted delays and risk to the release.

There are three main reasons for removing bloated code, benefiting developers, DevOps, and Security. 

1. Faster Development: Every piece of code in the image comes with a price. Unnecessary code slows down the whole building and testing process, leading to more time-consuming tests and lengthening the development lifecycle. Removing bloated code means you’re only testing the code required to run and not wasting cycles on unused code.

2. Increased Efficiency: Every piece of code consumes memory space. The more memory used, the slower the uploading, loading, and performance time. It also requires every monitoring tool (testing, performance monitoring, and profiling) to take more time and resources, even though it offers no value.

A significant portion of development time is spent on running pipelines to ensure no changes made at the codebase step on someone else’s toes. So you can imagine how speeding up this process can improve the product release velocity.

3. Improved Security: Although it’s not used, when loaded, bloated code is still vulnerable and can expose the whole product to attacks. If that weren’t enough – and really, it should be – scanners can’t distinguish between code that merely exists, and code that is actually used and loaded. That means the unfortunate application security manager will be inundated with false alarms from the multiple alerts generated during security scans. 

So, how do you find bloated code in your environment and images?

The task of automatically detecting bloated code in the environment is not an easy one. A native scanner will need to analyze what parts of the code will run in every possible flow, and that’s an impossible task with computation limits. Still, smart methods exist, such as unreachable code detection (available in most modern compilers), unused import of external libraries (e.g., JetBrains IDE products), and Rezilion Validate, which offers real-time detection on pieces of the code that are actually loaded, and can inform which security concerns should be taken care of as soon as possible, and which can be postponed until you ultimately refactor the project.