At a previous job, one of the other developers and I used to have a sort of competition on who could remove the most likes of code per week, while doing normal work.
I remember winning by 1.2 million lines one week when I found a second, unused, copy of a service embedded in another service’s repo.
I once worked in an office with a similar culture. The competition ended when someone found a header file containing a dictionary as a C array in some test code. They replaced it with a short function that reads the dictionary that comes with the distro, and removed 700,000 lines
One of the reasons that I hate C so much is that it’s incredibly rare to see diffs of any of these kinds in a language that doesn’t provide rich types. It’s common in C++ to review diffs that move duplicated code into a template or lambda (you may end up with the same amount of object code at the end, but you have less source to review and bugs are easier to fix).
At a previous place when I left I grabbed my additions/removals from all the git repos I’d touched in the time there. Came out overall at having removed 64k loc more than I added: https://twitter.com/Caius/status/1029384647661236224
Directly inspired from having read this folklore aeons ago. Always amuses me when it resurfaces.
I worked on a horrible product where QA people were expected to file two bugs a day, and engineers were expected to fix two bugs a day. It occurred to me that the QA people and engineers could team up and create easy busywork for each other indefinitely….
What they realized was that the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”.
At a previous job, one of the other developers and I used to have a sort of competition on who could remove the most likes of code per week, while doing normal work.
I remember winning by 1.2 million lines one week when I found a second, unused, copy of a service embedded in another service’s repo.
I do kind of miss that friendly competition
Now I’m imagining that the competition turned unfriendly and your coworker began to delete production services in order to beat your line count…
If no one complained, give this guy a medal!
This is also known as the “scream test” when used to measure whether or not a given thing was in use at all. ❤️
Sooooo … how long do you wait before declaring an absence of screams?
(Quietly considers EOFY processes that run once per year …)
If production kept operating correctly…why not? :)
Delete your backups system and production will keep operating correctly.
If that doesn’t raise any alerts, then it wasn’t operating correctly in the first place.
Delete the alerts
I once worked in an office with a similar culture. The competition ended when someone found a header file containing a dictionary as a C array in some test code. They replaced it with a short function that reads the dictionary that comes with the distro, and removed 700,000 lines
My favourite kinds of diff to review
One of the reasons that I hate C so much is that it’s incredibly rare to see diffs of any of these kinds in a language that doesn’t provide rich types. It’s common in C++ to review diffs that move duplicated code into a template or lambda (you may end up with the same amount of object code at the end, but you have less source to review and bugs are easier to fix).
Hehe, we had that at a previous job as well, but the highest score was in the thousands, 1.2 million is awesome, hahahaha
At a previous place when I left I grabbed my additions/removals from all the git repos I’d touched in the time there. Came out overall at having removed 64k loc more than I added: https://twitter.com/Caius/status/1029384647661236224
Directly inspired from having read this folklore aeons ago. Always amuses me when it resurfaces.
I have long had the .sig “Carter’s Compass: I know I’m on the right track when by deleting code I’m adding functionality.”
I worked on a horrible product where QA people were expected to file two bugs a day, and engineers were expected to fix two bugs a day. It occurred to me that the QA people and engineers could team up and create easy busywork for each other indefinitely….
I distinctly remember having read once that this actually happened at Microsoft (?) in the 1980s (?) but I can offer no evidence.
Maybe this? Not exactly what you describe, but close.
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/