It’s Halloween, time for scary tales with a flashlight and dressing up. It’s also time for DevOps horror stories.
Leaving dead and unused code in production can slowly sap productivity from engineering teams. Even for front-end development on websites, scrolling through the links to Java, JavaScript, and CSS files and trying to determine what’s still relevant can be time-consuming, leading to long hours, frustration, and mistakes.
Many years ago, I was working on my first big multimedia project for a light fixtures manufacturer to bring their expensive thick catalogs to CD-ROM…. We had a strict deadline and had a first working version after three weeks of hard work. But then disaster struck! The hard disk of my fancy blue iMac broke.
When everyone wants to write new code and create new functionality, who wants to wade through functions and scripts you didn’t even write and try to figure out what to get rid of and which files will take down your website if they are removed?
“We had to leave our hotel during the night, originally at 2:30. The day before, we checked several sites and some of them showed different departure times. Only after double-checking by our booking agency in the Netherlands were we sure we had to leave at 1:30 before we went to sleep… Seems we were not the only ones who had this issue. Everyone who booked early in 2024 for the summer had the wrong time on the booking confirmation.”
Think of your favorite horror movie. The heroes usually have to navigate clutter, trees, random people, or other obstacles as they escape the killers, supernatural threats, or whatever is chasing them. Remove the obstacles, they probably get away. Instead, they usually trip over something, stop their progress, and make a lot of noise.
Typically DevOps teams identify dead or unused code through static analysis or log review. But do you really want your best and most expensive engineers spending time reading through logs? Do your engineers want to do that?
“At Knight [Capital Group], some new trading software contained a flaw that became apparent only after the software was activated when the New York Stock Exchange (NYSE) opened that day…. The errant software sent Knight on a buying spree, snapping up 150 different stocks at a total cost of around $7 billion, all in the first hour of trading.”
Confusion can drag engineers into a scary game of guessing what’s unused or dead code and what isn’t.
How good practices lead to DevOps horror stories
Modern IDEs can detect unused and dead code via reachability analysis, but there is a soundness problem for classes and methods that aren’t 100% private. Code with a public access modifier could load so your tools will never report it.
Other times when code is tracked, it runs in a unit test. Technically, this code is not dead. Unfortunately, while test-driven design is a good practice, portions of code are alive only because a unit test fails when that code is removed. All this testing does is verify that unnecessary baggage fulfills its original design.
Although removing the unused and dead code makes the test go red, developers can also remove this test and speed up the overall build pipeline by not having to run it anymore. The best way to get a full picture of which code can be thrown away is to separately monitor test and production environments and see what happens.
Azul Code Inventory leads DevOps teams out of danger
Azul’s Code Inventory, a feature of Azul Intelligence Cloud, differs from typical static analysis tools and IDEs that detect unreachable code. The monitoring from Code Inventory occurs from the running JVM to identify entire classes or public methods that are present but don’t run. It’s a clutter finder, a tree stump remover. It accurately identifies unused and dead code for removal by precisely detailing what custom and third-party code is running.
Dead code detection improves developer productivity and developer happiness. It’s a burdensome chore to maintain garbage code whose sole purpose is to satisfy a test that ensures that the unnecessary code works. By detecting unused and dead code, developers can safely throw it into the trash.
