A thought I had recently is that staff/principal engineers who got their position by long tenure (not hired recently) should delete more code. Deleting code is actually one of the most difficult things to do in a project. To do it properly and without risking breaking things, requires not only vast and detailed knowledge of the system, but also knowing the context and decision around when the feature was added.
A long tenure engineer is the perfect fit for this. They know how to surgically remove the useless code. They remember all the hopes they had for the feature and when it failed to produce those results. They know well that code is not free, it's an ongoing cost to maintenance and complexity. This is not easy work to give to a junior. It's not even for senior engineers because they often lack the context and broad system knowledge. Only the long tenure staff engineer can confidently say, that feature failed, and I can remove it without breaking anything. If someone brings up sunken cost fallacy and how some users use the feature, only the long tenure staff has the background, respect, and authority to say, no this feature failed, it has 1% of the results we wanted, it's not worth the ongoing maintenance burden.
A staff engineer is supposed to a team multiplier through code. People often think of designs, refactoring, helpful tools, architecture discussions and documents. And it's true, these are all code related things that can multiply a team's efforts when done well.
But what better way to multiply a team's productivity than to reduce the size of the system? Think of how green field projects start. They feel so fast and progress is so quick. Then the features come, more and more, slowing down development with expanding system complexity and maintenance of code. How much faster and quicker can the team move after the staff engineer has reduced the system by 50%? It's like turning back the clock on an aging system. Suddenly it feels years younger, able to move quickly again, but this time with the right features in place from the experience of past years. And the team is happier, less useless code to wade through and understand, less strange bugs caused from code that supports a useless feature.
For finding and deleting dead code anyone can get up and running by using something called tombstones, marking pieces of code as dead and then logging their invocations to see if they are really being used and if yes then how so.
It is much more powerful than simple static analysis and is setup as a continuous destruction platform alongside continuous integration.
It's never actually useless code, it's the code that is _almost_ there. Then there's the whole political dance where one team still uses it because the replacement isn't quite the same and now you're solving some obscure use case and prioritizing the work gets done. Plus, it's likely the original author is still present so you have to placate them too.
I definitely take on the grim reaper role and make deletions happen. But it does take all the skills in the post.
We're going through this at my company currently. The best way to increase the capacity of a small team is to decrease their maintenance burden and the surface area they have to cover when implementing new features or changes to a complex system.
After recently joining a new company this was one of my big contributions, I went through the whole codebase and removed legacy/unused code, or merged code that was slightly different into a more general version.
Spent a good 2 weeks on this but the result was around 120 files changed and over 4000 lines removed, it felt great! And it was also an amazing opportunity to understand the codebase and ask the right questions to other team members when figuring out what was outdated and what wasn't.
I'm sure it was great, but always beware to change two similar codes into a more generic one, when what was originally two served two different parts of the system.
In that case, what can happen is once the requirements change for one part of the system, now you must change a generic component in such a way as to not disturb the other part using the same component.
That way madness lie. (Of course, cut-n-paste programming is also madness inducing.)
>A thought I had recently is that staff/principal engineers who got their position by long tenure (not hired recently) should delete more code...
I still consider one of the highlights of my career to be a release of mature software where I was able to deliver the whole additional feature set on time, AND reduce the overall size of the codebase by about 15%. There was so much cruft from a long history of incremental development that there was duplicate logic, lack of single responsibility, and many bits of code that were 90% similar and could be made redundant with some basic abstraction.
In some of the less decent companies that I've worked on, those supposedly janitorial tasks were pushed to junior engineers, while more senior ones were left to do be architecture astronauts.
Searching code for usages of a piece of legacy code that you know is probably not used anywhere can be a good way for juniors to learn the code base, though.
I don’t disagree that purging unneeded code has value. That being said, software systems are so complex, isn’t it better to just leave code alone if it’s not negatively impacting the business? How many orgs have a micro service architecture that is so well tested that you can delete code from one service and demonstrate that won’t cause a failure in some other service? I haven’t seen one yet.
Deleting code shouldn't be this hard, by logging how often a piece of code is being invoked in production one can start planning purges of unused dead code. It has to be done carefully but by no means it is so complex that it shouldn't be done.
Dead code is often a negative for maintenance, understanding and performance. With version control one can always go back and recover deleted code that proves to be useful later on.
* When new folks are onboarded, they should be spending a lot of time looking through the code base. Maybe on their own, maybe as part of other tasks, but they'll be reading this dead code multiple times.
* If the dead code is an entire method, and hasn't been used in a while, it probably doesn't work. What happens when someone calls that method now?
* Your CI/CD pipelines spend time building (and probably testing) dead code.
A long tenure engineer is the perfect fit for this. They know how to surgically remove the useless code. They remember all the hopes they had for the feature and when it failed to produce those results. They know well that code is not free, it's an ongoing cost to maintenance and complexity. This is not easy work to give to a junior. It's not even for senior engineers because they often lack the context and broad system knowledge. Only the long tenure staff engineer can confidently say, that feature failed, and I can remove it without breaking anything. If someone brings up sunken cost fallacy and how some users use the feature, only the long tenure staff has the background, respect, and authority to say, no this feature failed, it has 1% of the results we wanted, it's not worth the ongoing maintenance burden.
A staff engineer is supposed to a team multiplier through code. People often think of designs, refactoring, helpful tools, architecture discussions and documents. And it's true, these are all code related things that can multiply a team's efforts when done well.
But what better way to multiply a team's productivity than to reduce the size of the system? Think of how green field projects start. They feel so fast and progress is so quick. Then the features come, more and more, slowing down development with expanding system complexity and maintenance of code. How much faster and quicker can the team move after the staff engineer has reduced the system by 50%? It's like turning back the clock on an aging system. Suddenly it feels years younger, able to move quickly again, but this time with the right features in place from the experience of past years. And the team is happier, less useless code to wade through and understand, less strange bugs caused from code that supports a useless feature.