3 ms·

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 l

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 6y ago
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 6y ago
  >> 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 6y ago
    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.

zizee 6y ago

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 6y ago
>> 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 6y ago
  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.