How many times have you said, “I must clear out that shed, loft, garage?”
We’ve all said it and our intentions are always good, but the clutter seems to build up, as does the sense of dread knowing that the tidy up will take even longer. Well, that is how most engineering vice presidents feel once they realise how much code in their applications is actually dead. Like the clutter taking up space in the loft or garage, unused or dead Java code is a problem any time they go into “the garage” to do something because instead of doing what they came to do they end up getting bogged down in the clutter. And the longer it is left the more of a drag it becomes on productivity for the engineering team.
Spring cleaning
The Dead Java Code Society is one of the least desirable clubs to belong to, as to join carries consequences. While the CIO may not care if their engineers must filter out unused code to deliver functionality the organisation requires, questions will be raised if new functionality is not delivered in a timely manner. No one wants the engineering team to be perceived as slow to deliver value to the business, but that will happen if they must do a spring clean every time they develop new code.
Equally, the engineering lead needs to avoid their developers’ time being consumed by mundane, repetitive tasks such as sifting through dead code. In April 2024, for example, newly published research showed 58% of IT professionals were experiencing burnout, so anything that adds to frustration may increase the likelihood of talented engineers leaving. In today’s highly competitive jobs market it is crucial to avoid such pressure.
Security fire drills
Engineering veeps want their applications to be secure, so usually they accomplish this in coordination with security teams who scan for Common Vulnerabilities and Exposures (CVEs). Unfortunately, these scans produce other false positives that consume time just like dead code. The average Java application contains unused dependencies and scanners flag those unused dependencies as urgent risk, creating a fire drill for development teams.
We all know the threat of cyber attacks is growing, and Java recently faced a significant threat in the form of the Log4J vulnerability. Any engineering lead would have been concerned to read Veracode’s report that more than two years after the incident, it found 38,278 unique applications running Log4j versions 1.1 through to 3.0.0-alpha1 across 3,866 different organisations.
Part of dealing with such cyber threats is knowing where to focus efforts. What if a vulnerability detection tool generates false positive? Every time it identifies a vulnerability it must be investigated but if it is unused code then it is not an issue. However, it will still need to be investigated slowing the engineering team down.
The solution to this problem is similar to the detection of dead code; track what runs and focus on that.
So how do you avoid membership of the Dead Java Code Society?
Tidy code, tidy mind
Dealing with unused Java code can become a significant productivity issue for the engineering team. While there is no universal data on the potential scale of dead code within applications, one academic study cited a report where a code examination of an industrial software system found 30 to 50% of the total source code was not understood or documented by any developer currently working on it. This was identified as dead code. If Java is so widely used across enterprise environments, this data would suggest one should prioritise cleaning out the metaphorical code shed.
The good news is that this does not need to distract from other requirements, because a combination of the right framework and tools can enable you to chip away at the problem without it becoming all consuming.
The first step is to create a code inventory. This does not need to be a complex process as there are tools available to monitor which code is used and unused. This can run passively in the background and build up a code inventory that can be worked on.
The next step is to agree a policy for deciding what is dead code and a process for removing it. While there may be obvious indicators such as code not being used for a long time, it is also important to consider the consequences of removing it in case it might have a knock-on effect elsewhere in the Java environment. There is also no pressure to remove all the unused code at once. The engineering team should agree when to focus activity – perhaps removing a couple of sections of code during each developer sprint.
If an organisation gets its approach to dead Java code right, then ultimately the engineering team will be more productive.
Like the old “tidy desk, tidy mind” adage, removing clutter means teams can focus on what is important, rather than having to sift through junk. In one example from Goldman Sachs, Darshan Mehta, the organisation’s VP of core engineering, highlighted the benefits of reducing the size of a codebase by 67%.
He suggested it reduced complexity and made the codebase easier to navigate and test, which also gave greater confidence in the testing process as well as saving time that could be invested elsewhere. More importantly, the build and delivery pipelines were faster, as there was less code for static analysis and less tests required, meaning the release cadence of the product improved to more than 250 releases per year.
Absolve your membership
By avoiding membership of the Dead Java Code Society, the you create bandwidth that can be applied to all the other complexities of managing Java-based environments. More importantly, it will allow developers to do what they like doing: writing new code that is actually used.
Eric Costlow is senior director of product management at Azul, a Java platform services supplier with clients including Mastercard, Puma, Taboola and Workday. He began his IT career as a student in Illinois and has since worked as both a technologist and a technology writer. Between 2013 and 2016, he worked as a principal product manager at Oracle where he led on addressing a series of Java security issues.
