Mark Needham

Thoughts on Software Development

Coding: Unused code

with 10 comments

An interesting problem that we have come across a few times over the past 6 months is the dilemma about what to do when start work on a feature and get part way through it before it gets descoped from the current iteration, maybe to be picked up later on but maybe not.

The easiest, and there most common, approach is to just leave the code in the code base half complete and then hopefully return to it at some later stage.

In theory perhaps this doesn’t seem like such a bad idea.

The problem is that this code is clutter and create confusion since other people in the team come across it and they’re not really sure what to do.

In a way it is comparable to commenting code in that it creates doubt in people’s minds about whether or not the code is actually important or whether they can delete it.

One of the annoying side effects of testing this type of code is that as a result of those tests it will still have usages in the code base which means that the IDE won’t be able to identify it as unused code. If it did then you would probably feel more confident about deleting it.

On top of the problems that we get from leaving commented code in the code base it is also quite likely that the complexity of the code base has been increased from adding this code and since it’s not currently being used it is now unnecessary complexity.

We noticed this in our code base when our original plan for release was to have three different customer work flows through our application.

Two of the work flows were descoped quite close to the release but were needed in the second release so we didn’t go through the code base and delete everything, we just left it in there.

The thinking behind this decision was that we would be needing that code quite soon anyway since we would start working on the next release which had those features in straight after we did the first release.

As it turned out the first release ended up being a little later than planned and when we got back to implementing those features the details of how the business now wanted them to work had changed to such an extent that what we had done previously was actually more of a hindrance than help.

We ended up having to rewrite a lot of the functionality.

In lean terms this was therefore the worst kind of work in progress since we know that it is half finished, currently adding no value and we’re not sure exactly when or even if it will eventually add some value to the end user.

We actually have a similar situation with a feature which we started work on but which was pushed out of the current iteration.

The approach this time was to go through the code base and get rid of all the code and then just re-implement it when we need it – the original code is in source control if we need to refer to it so it’s not gone forever.

Another approach which Dave suggested which we considered but decided not to do this time was to keep a copy of the unused code on a branch so that if/when that code is needed we could just switch to the branch to continue working on that functionality.

I guess this approach might work quite well if it really is a short delay until we are actually going to implement the feature.

Perhaps surprisingly given that things change quite quickly with the agile approach to software development I can’t actually remember coming across this problem before but I’m sure it’s quite common so I’d be interested to hear what others are doing.

Be Sociable, Share!

Written by Mark Needham

August 21st, 2009 at 8:56 am

Posted in Coding

Tagged with

  • Jeremy Gray

    Cut that code into a branch, nuke it in your main line of development (or cut a new main line of development, or whichever of a number of rough equivalents that best suit your chosen branching model), and then move on. If you do want to look back on it or even dredge it back up as it was, you’ll have that branch there.

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #417()

  • The approach of removing it from the code base feels much cleaner and more satisfying to me.

    If you do need the feature at a later date you should still have the knowledge of how it had been partially implemented and you should be able to refer back to your source control system to see what actually had been done complement this knowledge.

  • I’m with Mark Dalgarno on this. Remove it, and you _could_ refer to it later.
    In practice referring back to it rarely happens – as you say, the business idea of the abandoned feature has evolved in the meantime, so it is much faster to write new tests with fresh code.
    I recommend throwing away code often. If there is one thing I should (still) be doing more is throwing away code e.g. keeping code after a spike and then moulding it into production ready code takes much longer than throwing the spike away and working again from tests, but still I can’t help myself sometimes…

  • The idea of removing the code from the current version, and leaving the footprints in the source control system is appealing, but it does have its probblems.

    Having taken this approach without regrets several times, I eventually found myself actually needing to look up some old unused and deleted code.

    Unfortunately it was very hard to find. Most SCM systems I have used treat the file as the key repository item, and make access to the history of deleted files quite tricky. This is just about doable if you can remember the name of the file in question, but this is not often true in a highly fluid, mercilessly-refactoring code base.

    Finding the various bits which comprised the deleted feature turned into quite a forensic exercise.

    My recommendation is that you should *always* meaningfully tag or branch the repository state before performing such a deletion. This few seconds of effort can save hours of frustration if you do ever need to look back.

  • Vijay Aravamudhan

    One other (hard-line) approach is to simply nuke the code. If it is sufficiently soon AND important that it needs to be resurrected, someone on the team would remember that this code was checked in (and could later find it with the commit history logs – assuming that you checked it in at least once). This approach also allows the [possibly] new pair to implement it in a different manner (debatable whether the new one is actually better or not) – but hopefully with more knowledge of the changed business process/requirement.

  • ilivewithian

    I’m with Jeremy, branch the code. Even if you’ve ended up with the code in the main trunk branch it, then delete it from the trunk.

    I try to keep the main trunk as clean as possible, that way moving towards continuous deployment becomes more realistic.

  • Interesting ideas, I guess perhaps the option of branching/tagging the feature and then removing it is probably a reasonable approach.

    Strangely enough straight after I posted this I was working on some code with a colleague and a feature we originally implemented 6 months ago but which was then deemed unnecessay was rewritten in an ever so slightly different way cause we had different people working on it the second time than the first and we didn’t pick up on the fact it was already done a different way!

    Quite frustrating because the old code is now getting in the way and has increased the complexity of what we’re doing.

  • We have been refactoring our code base of last project and face this issue too. Unused and long comment out code make me sick during code review. It cost me lots of time to find out if a specific method is used or not, code coverage is very useful in this situation but it isn’t always right in all cases. I think the quickest and most efficient approach for this issue is removing it completely. If developers need it later, just come to code repository.

  • Of course, don’t forget to leave a meaningful comment at where code is removed.