Do you keep old feature code just in case a client asks back?
by•
Bloated files are the worst part of maintaining a growing project.
We tend to hold onto old code because it feels like throwing away actual work, even when nobody has used that feature in months.
Cleaning up dead code always makes the app faster and cuts down build times, but it is super hard to convince the team to delete it.
Have you ever deleted a large chunk of code only to realize later that you actually needed a piece of it back?
18 views
Replies
Git is the "just in case" folder, so I delete. My current app started from the architecture of an older photo app of mine, and its photo and video features were deliberately left out. Later I did want two of them back, the home screen widget and the Live Activity. I did not restore the old code though, I rebuilt both for songs on the same architecture, using the old project only as a worked example to read. That is the real answer to your question for me: when you need a feature back, you rarely need the old code back, you need the old decisions, and those are cheap to read from history. Dead code kept in the tree costs you every build and every search in the meantime.
@gbasovv That's a good point. Sometime we don't need the old code itself, just the idea behind. Keeping the project and checking.
Git history when needed sounds much better than carrying unused code around for month.
@norma_wick Exactly. And the leftovers that hurt most are not even code. My translation files still carry strings from the old photo app's flows, and every time I add a key in every language I scroll past them. Code shows up in the compiler, so it gets noticed. Text, config and old flags just sit there quietly, so those are the ones I now try to delete in the same commit that removes the feature.
@gbasovv That's true. Old translation strings and config flags can be easy to overlook because they don't cause obvious problems. Cleaning them up along with the feature makes the whole project easier to maintain.