As a code base ages it is natural for its SLOC count to increase or, at best, not move as more functionality is added. This is inevitable but also perfectly fine. If we look at the Gridcoin source tree we can see that even though a lot of things have been added, much of the obsolete has been removed which is why the graph is sort of flat up until The Great Code Removal of 2017:

Those who have followed me on IRC or Slack know that I have an almost sickly obsession with code removal. To me, removing dead, or zombie code is the easiest and most relaxing form of refactoring and offers instant gratification with almost zero risk involved. Occasionally the worst thing that can happen happens; you removed code which is used on another platform and you just add it back. This removal has become a part of my daily routine and is something I do when I'm too tired to think but want to do something.

Code complexity

Every line added to a program introduces complexity but in return you gain functionality. Inversly, every line removed removes the functionality but also reduces complexity, right? It seems pretty straight forward but there is an exception to this though. I would argue that removing all references to a piece of code while keeping the piece of code itself (thus making it a zombie) actually increases the overall complexity of the code base in addition to what the piece of code adds in itself. What used to be a useful member of society is now an ambiguous blob of text. The piece of code now imposes questions to the reader.

• Why is this still here if nobody uses it?
• Should I use this or is there something wrong with it?
• Is the intention to use it later on?
• Who the hell authorized this?

In order to understand why the code is unused you suddenly have to see a much greater picture and be aware of historical decisions. You have to move towards becoming an expert when you really shouldn't have to.

Another thing to keep in mind is the complexity perspective from a new viewer. The more code you have to absorb and consider, the harder it becomes to understand the flow.

Build times?

This is probably the most obvious reason for code removal.

More code = more lines to compile = longer build times.

Since we have undergone so many removals you would expect to see an equal drop in build times. The reality is that the sheer amount of source in c/cpp files actually has less of an increase on build times than you might think. Sure, a lot of code increases the times, but a small reduction doesn't do much which becomes apparent when you add it to the chart:

Compilers are usually quite fast so removing 20 lines of code is not going to have a noticable impact. The drop in 3.5.8.9 comes from improved header discipline which does much, much more for the build speeds. Before that all versions compiled with a difference of +/- 1 second.

Maintenance

It may sound counter intuitive but unused code has to be maintained almost as much as live code, except for refactoring for performance or readability. Every time you do a refactoring task which involves the dead code you have to make sure it still compiles, that its unit tests are working and that its documentation is still valid. If the code you refactor does not add value you are doing the work for nothing.

Conclusions

I am not alone in this crusade. ifoggz and Tomáš Brada have removed both unused RPC commands and a slew of obsolete Proof-of-Work code. The result of that is the reason for the massive code dip in the development branch. As a result we now have ~5000 fewer lines. That is code we never have to see again, never have to consider and never have to explain. It's a great time to be alive.