On March 13, Azul gathered Java developers, enthusiasts, and Java Champions to celebrate 30 years of Java. An impressive lineup of luminaries gave presentations, including Developer Advocate Gerrit Grunwald. Gerrit explained what unused, dead and zombie code are, why developers hate them, and how to handle them.
“We hate code.” Azul Developer Advocate Gerrit Grunwald quoted a customer’s words to him, and now he was going to demystify them.
Most developers have been told to “just build” a project, even if it’s imperfect, and someone will fix it later. But will they? And who will maintain code that isn’t used? Unfortunately, probably no one, which creates a problem that only grows with time. Check out these statistics Gerrit shared:
- Maintaining bad code for around four hours a week equates to $85 billion a year.
- Every 100,000 lines of code that a company owns leads to $361,000 of technical debt.
Let’s define bad code and dead code
Bad code means legacy code, which can be defined by the following criteria:
- Written for operating systems, hardware, or APIs that no longer exist.
- Cannot be tested automatically (so you can’t really test it now).
- No longer developed or maintained by the original developer (or by anybody).
- Lacks documentation, so we have no idea really what it does.
In short, if you’re afraid to touch it, it’s legacy code.
How do you handle legacy code?
There are different ways of handling it. Gerrit focused on refactoring it and rewriting it from scratch.
Refactoring legacy code
You need to know the code before you can refactor it, so you have to study it and understand it. You use static code analysis tools. Even with these tools, it’s a time-consuming process, which is the biggest problem. “Refactoring means you have to really understand the code, work through the code, and then need the time to refactor it using these tools,” Gerrit said.
Rewriting legacy code
“Sometimes it sounds weird that this is really a solution,” Gerrit said, “but sometimes it makes sense.” But again, before you start rewriting code, you need to understand what it does. This is like a new project with all the costs and time requirements of a new project.
Is anyone using this code?
How do you figure out if code is really used, right? Usually it’s unreachable code that you can’t even reach from other methods. It can be redundant functions that do exactly the same thing but have different names that are called from different parts of the application.
As long as both functions work, what’s the problem?
- Reduced readability – Understand the logic of the code is time-consuming and no fun.
- Increased file size – Bigger containers take longer to upload, take more space, and cost more.
- Bugs – Bug finders find the code and triage takes time whether there’s an actual bug or not.
- Security issues – Scanners alert you that parts of the code are vulnerable, but you don’t know if it’s reachable in your code base.
Gerrit explained that IDEs like IntelliJ and OpenRewrite, which is an open-source project from Moderne that enables developers to effectively eliminate technical debt.
NEVER BE EXECUTED
Defining zombie code
Zombie code is maintained, which means you have tests for it. You deploy to production, where it is never called. All tests are green. But only your tests call the code, so it’s never called in production. It’s reachable and it’s good, so the tools Gerrit discussed earlier won’t find it. So it’s fine, it’s tested, it works, but nobody can tell if it’s used. So how can you find zombie code that sticks around but is never caught in production?
You can only find it by running a system to find it at runtime. One method is called tombstone logging. To see a live example of tombstone, watch Gerrit’s entire presentation in the Duke Turns 30 section of our website.
Marit had many other tips and examples for developers. For those, you will have to watch her full presentation on the Duke Turns 30 section of our website.
