One project I was on someone added a tool and posted the results of the past week of number of lines of code added, my count was -5900 and I had been put at the bottom. This was a legacy project.
Its pretty easy to explain why removing a bunch of complexity and replacing it with something smaller and meeting the customers requirements better is obviously the goal on any project. Everyone that added lines had made things more complex. Its obviously a useless measure for productivity or saying anything of note about the work at all other than the lines of code making up the project and how it is changing over time.
> A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.
> ...the authors observe that people consistently consider changes that add components over those that subtract them" -- be it bricks or regulations, so it works like this for real as well as for abstract things.
> Our conclusion is that people systematically overlook subtraction; it’s not that subtraction is always better
My personal experience agrees with these findings, but I think they missed something more important. People try to change things because they want to see something new in the real world. But from ideas to real world impact there is always at least one level of 'approving' you will have to go through. And adding things will generally have less risk associated.
Besides that, I think our education system doesn't train us to remove things. Everything we learn is incrementally built upon what was already there. So our default mode of thought is to add things.
Now imagine we have 2 developers, one how always solves problems by adding something new and another one that always refactor things to keep things efficient.
My guess is that by only adding things you will end up delivering more features with less bugs. Sure your code will be slower and at some point it will become impossibly complex to manage, but it takes quite a long to time to get to this point.
After writing this message I've realized that 'making things easy to delete' is a pretty important feature.
People try to change things because they want to see something new in the real world
my personal feeling on this is rather, removing someone elses code is like dismissing their work. and generally i don't want to do that. if it is not clearly a bug, then i'd hesitate. someone wants this feature. taking it away would not be nice to them.
it may be similar to the problem of design by committee. everyone wants to get their favorite features in, and we are more concerned about our relationship to our colleagues than the end result. here, we can solve this in a way to make everyone happy, but without stopping to ask if removing that mis-feature would actually make anyone unhappy.
thinking further, i think this is also a problem with personal ownership of code or features instead of team ownership. this feature is owned by X, i can't remove it without his permission, or without a discussion in a meeting. leaving it in and working around it is the path of least resistance
Whether or not removing features might be "more efficient", in nearly all cases, if you remove a feature that's been part of a software package—whether external or internal—some nontrivial fraction of the people using it are going to be angry, because you just broke their workflow.
The only way you can possibly avoid this is if, in addition to removing that particular feature, you add a feature that does the same thing fully automatically, and does so correctly in every instance.
(Even then, some people will complain about it, but at that point you just have to accept that as a cost of progress.)
Coporate culture encourages adding. Half your job is justifying keeping your job. It takes a lot of swagger/social capital/clout to subtract and be loved for it. Or you need to work somewhere (a company or protected team) with a first principles thinking culture (and not a cargo cult one) which is very rare.
In personal life I think people do often subtract. They give up X where X is harmful. They simplify. Not everyone but many. It feels like a natural part of life.
I gave myself carpal tunnel replacing over a hundred copies of the same five lines of code with an n² complexity with a single implementation, so then I could fix the perf issue later. -500 lines over a holiday week, which was nice, but not as nice as landing the changes to the shared function and making 2/3 of the app 10x faster with the test data, which was ultimately going to be a fraction of the real data.
Don’t large scale refactor in vim folks, especially if you haven’t memorized all of the shortcuts (I hadn’t discovered block indent until weeks later. Ouchie)
But then again, the point is not about individual examples really – the point is that whichever metric you choose, with time you'll see diminishing returns followed by negative ones.
In case of doubling removals, you can easily game it by dumping json files for tests, then removing them ie. in favor of generator etc.
What's interesting is universality of this phenomenon (strong goodhart's law?) – overfitting in llms, using metrics discussed here and why it makes sense to vote on opposite ruling party etc.
Its pretty easy to explain why removing a bunch of complexity and replacing it with something smaller and meeting the customers requirements better is obviously the goal on any project. Everyone that added lines had made things more complex. Its obviously a useless measure for productivity or saying anything of note about the work at all other than the lines of code making up the project and how it is changing over time.