It's not just old managers that dislike negative lines of code: Static analysis tools dislike them too, under the right bureaucracy.
At a certain huge company that sells seeds, they decided to start having both a base test coverage target, and a specific plugin that demanded that the coverage never went back more than half a percent from the high water mark on any given project. The engineering managers thought it was a good idea: As time goes by, we'd have better code coverage!
I joined a team that had an application full of repetitive code, because nobody had spent much time thinking about reuse. I decided it was bad for maintainability, and the team let me rewrite a big chunk of repetitive, well tested code. I shrunk the codebase by a good 10K LOC, and it still did the same thing. Teammates liked what I had written, and everyone was happy. But when I pushed it, the build refused to deploy, because now the code didn't meet coverage standards.
The manager was mad at me: you wrote all that code, but I guess your unit tests were sloppy! he said. But when I went and looked at the code changes, I had a 100% code coverage. Since I am not a football player, I just couldn't give 110%. So then we look at the reports, slowly, and saw that while I had full code coverage, the code I was replacing also had full code coverage, but mine was so much smaller, our total coverage percentage went down! 1000 lines of uncovered code, in a codebase with 30K lines, gave us better numbers than the same lines in our shinier 20K LOC codebase. And building tests for some really old, badly factored code just wasn't in our top list of priorities.
The people in charge of this system refused to change it, even though it was really not helping things in our case. So what did we do? Fool the tool, of course. Added a bunch of well tested dead code that was never going to get called in production, and wouldn't even get built into the binary, thanks to some packaging magic. We put it in a separate module, clearly marked as 'dead code to make Sonar happier', and we went our merry way.
> And building tests for some really old, badly factored code just wasn't in our top list of priorities.
Really? I always thought that it's the old, ugly and brittle code that needs unit tests the most. Especially right before the moment you finally decide to rewrite it.
At a certain huge company that sells seeds, they decided to start having both a base test coverage target, and a specific plugin that demanded that the coverage never went back more than half a percent from the high water mark on any given project. The engineering managers thought it was a good idea: As time goes by, we'd have better code coverage!
I joined a team that had an application full of repetitive code, because nobody had spent much time thinking about reuse. I decided it was bad for maintainability, and the team let me rewrite a big chunk of repetitive, well tested code. I shrunk the codebase by a good 10K LOC, and it still did the same thing. Teammates liked what I had written, and everyone was happy. But when I pushed it, the build refused to deploy, because now the code didn't meet coverage standards.
The manager was mad at me: you wrote all that code, but I guess your unit tests were sloppy! he said. But when I went and looked at the code changes, I had a 100% code coverage. Since I am not a football player, I just couldn't give 110%. So then we look at the reports, slowly, and saw that while I had full code coverage, the code I was replacing also had full code coverage, but mine was so much smaller, our total coverage percentage went down! 1000 lines of uncovered code, in a codebase with 30K lines, gave us better numbers than the same lines in our shinier 20K LOC codebase. And building tests for some really old, badly factored code just wasn't in our top list of priorities.
The people in charge of this system refused to change it, even though it was really not helping things in our case. So what did we do? Fool the tool, of course. Added a bunch of well tested dead code that was never going to get called in production, and wouldn't even get built into the binary, thanks to some packaging magic. We put it in a separate module, clearly marked as 'dead code to make Sonar happier', and we went our merry way.