I wonder how many systems have "Zombie Code", left in place and neglected or forgotten?
I don't wonder. The answer is "all of them".
I tend to agree with William, I think we would find the majority of systems with it.
my nickel Canadian
@dcontesti @denbesten In that case how much would you pay for the bug bounty?
Would it be worth US$1.8 Million like Zoom in 2001?
In the old days where RAM and ROM space ensured tight programming and efficient means to provide the best you could achieve or have we just grown lazy with the luzury of Gigabytes or more being available?
Could we apply the same principles for the development of APIs?
What if we charged developers and programmers for each additional byte of code, which was surplus to requirements?
Or reward the developer raised the least zombie code 😉
Now onto the discussion..
The article seems to be referring zombie code as dead code or unreacheable code, but there's some distinctions between them imho. Dead code and unreacheable code usually refer to program lines that under no circumstances will be executed. It is a programming mistake, something modern IDE can help to spot before compilation. Some language compilers, like java, will raise compilation error on unreacheable code. Another example is a private function that is never called within a java class. No compilation error, but IDE will mark a warning.
Zombie code, on the other hand, are code that is in the codebase but seems never been called. Today it is not that easy to determine whether a piece of code is "zombie". Think about advanced programming language features like dynamic class loading, byte code generation, IoC (inversion of control as in programming concepts, not indicator of compromise) interceptors.
Designs like configuration-driven systems (e.g. ERP system where the exact function getting called is determined by configurations as setup in the database) could also render identifying zombie via dynamic analysis futile, well, unless there is an absolute 100% test coverage - which is something infeasible in reality most of time, due to exponential scenario combinations.
Some other examples are code that is there to take care of specific functions not directly affecting system features, e.g. different runtime environments (if-else for handling runtime differences in OS or containers, standalone etc), for special ad hoc calls, for system maintenance use cases, etc.
Finally, there is also something about programming practice and development lifecycle. What if a developer during a day's work prepared some private function in advance, maybe for related features to be developed in the next development cycle? The developer specifically marked this as private to prevent accidental access by other teammates. It defintely looks like zombie code, and both static and dynamic analysis will agree it is, but it is in fact not.