HN Explorer

Ask HN: Would you pay for a SaaS product to cleanup dead code?

6 points by zizee ↗ HN
Sometimes as your codebase grows it is hard to know when parts of your codebase can be retired. This issue impacts dynamic languages like Ruby/Javascript where it can be difficult to statically analyze code for such problems.

I have an idea for a product that would monitor your code as it runs in production with the intent of identifying code that is no longer called. The tool would then open PRs on your codebase to:

1. add tracers to give confidence the code is truly unused, and; 2. remove the code no longer being used.

Obviously, security and performance would be paramount.

Is unused code something that your team is concerned about? Would this be something people would be willing to pay for on an ongoing basis?

20 comments

[ 4.4 ms ] story [ 53.3 ms ] thread
quickthrower2
Cleaning up dead code is equivalent to the halting problem in JS
zizee
I agree that it would be difficult to build a tool that could guarantee the code will never be called. Instead, I want to build a tool that can allow developers to home in on good candidates for cleanup.

I am proposing to monitor code as it runs in production. This will allow us to be confident in which code is actually getting called, and the inverse: which code is called infrequently. Then we could install probes in code that is suspected to be dead. e.g. explicitly log when the code is called. Then after an appropriately generous period of time (a month or two), if the code still has yet to be called, then we can be more confident when removing it.

phekunde
I will be more interested in a tool that will reduce, if not eliminate, technical debt :)
zizee
Yes, that would be great :-) I think static analysis can go a long way to helping with this, but again with dynamic languages it can be hard to cover all the bases. I would welcome hearing your ideas on specific tech debt you are trying to avoid.
[deleted]
(comment deleted)
gitgud
> Is unused code something that your team is concerned about?

Not really, unused code is rarely a problem that businesses care about its unfortunately a user's problem.

I think businesses would care a lot more about code duplication. I can imagine a tool which uses fuzzy matching to find different levels of duplication in a codebase. It might even be an easier problem to solve.

zizee
When you say "user's problem", is the software dev the user? Or the end user? If you are saying it is not an issue for devs, I disagree. Dead code / used code paths add to the mental load and mantainance burden. Whether this is a significant enough issue to make a paid for product is another question :-)
gitgud
Well, I'm just saying it's not an issue that businesses care about.

Removing a few extra lines of unused code in a product will have basically no visible effect to the end user. And might have no measurable effect on the burden of maintenance either.

Maybe if you could find a way to measure the complexity that you're reducing, in some kind of metric, then businesses will care.

zizee
Thanks, this is exactly the sort of feedback I'm after.
pearjuice
Why would I pay for this when my IDE show me this and products like Sonarqube exist which does much more than just checking dead code?
zizee
Does your IDE and Sonarqube really have the ability to detect that certain code is never run in production? I don't believe static analysis can ever truly do this, especially for a dynamics language like Ruby.
maps7
From a non-tech company pov: no, unused code is not a concern.
zizee
Thank you for the response, much appreciated. I guess the target market for the tool would be dev teams that place a high value on code quality.
davidajackson
No because in startups an automated program can't tell the difference between unused code and code that was commented out/not being called. While we would all like to pretend that none of us do this because it's not best practice (especially if we were asked this in an interview :) ), in startups it's common, because there are sometimes more important things to worry about.

You might have more luck building security tools in my opinion--that seems like a bigger implication of unused endpoints, code, etc -- maybe call your potential customers and ask what tools they need around that.

zizee
Thanks for the thoughtful response.

> automated program can't tell the difference between unused code and code that was commented out/not being called

Can you expand on those two types of unused code, and why you would want to keep one around longer term?

> in startups it's common, because there are sometimes more important things to worry about.

Do you think once an organization starts maturing (i.e. not so much a startup anymore) that cleanup work might take on more important ance?

> You might have more luck building security tools in my opinion--that seems like a bigger implication of unused endpoints, code

Yes, security is another good aspect of cleaning up unused code. I think some insights into more/less popular features of your sotware could also be useful/interesting.

> maybe call your potential customers and ask what tools they need around that.

Absolutely.

davidajackson
>> Can you expand on those two types of unused code, and why you would want to keep one around longer term?

What I meant by this (and I worded it badly) is that there's a difference between unused code that is unintentionally left and unused code that is left purposefully. I suppose commented out code indicates a conscious decision to leave code in but have it not run, but not everyone might comment it out... and in the case where code that doesn't run isn't commented out, you don't know whether that was unintentional or not. But like you say, in a big company, this should be cleaned up, and in startups, there's often too much need to put out other fires. Seems like big companies should be your market for any cleanup tool, not startups.

Also say you inherit a codebase, running an automated program that deletes anything that's not being called... feels iffy. Maybe a previous engineer didn't quite finish something... ideally that won't happen but I imagine it might. Maybe you could make something that lets people check off changes one by one.

>>Do you think once an organization starts maturing...

Yes

zizee
Thanks for clarification. I thought that was what you were saying originally, but better to check :-)

> Seems like big companies should be your market for any cleanup tool, not startups.

Yes. For a team getting something off the ground, a bit of dead code hanging around is not really a concern relative to the scramble to find product market fit.

> running an automated program that deletes anything that's not being called... feels iffy. Maybe a previous engineer didn't quite finish something... ideally that won't happen but I imagine it might. Maybe you could make something that lets people check off changes one by one.

Agreed. I was thinking that the service could open pull requests to the repo, one per code block. The PR would then have to be reviewed/approved before merging. It could do this as a two step process. First to add signal flares on suspect code, and then a follow-up PR to do the actual deletion.

alt_f4
Yes, if done perfectly. Then I don't need to second guess it and potentially waste time if the thing removed something important by mistake.

But that's equivalent to solving the halting problem, which is impossible. So, no.

zizee
I think if you monitor the code running in prod for a while, it can give you confidence that the code is not used. I am proposing a tool that would help you narrow down logic that is not used, and to automatically create PRs that are manually reviewed/approved i.e. not taking the dev out of the loop.