
Ask HN: Would you pay for a SaaS product to cleanup dead code? - zizee
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&#x2F;Javascript where it can be difficult to statically analyze code for such problems.<p>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:<p>1. add tracers to give confidence the code is truly unused, and;
2. remove the code no longer being used.<p>Obviously, security and performance would be paramount.<p>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?
======
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.

------
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.

~~~
quickthrower2
Cool!

------
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.

------
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.

------
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.

------
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.

------
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.

