The Horizon Effect

Today I got started on one of the more fun things in software development - removal of old code.  Not a refactoring of functionality, but outright removal.  It's been a while since I had the chance to do this.

It's cool, getting to excise code and make the codebase smaller and more efficient.  The feature unfortunately was not wrapped in a simple method or methods, but the functions and data are all well-named, so it's a simple search and destroy replace.

But I was musing that this was something that gets ignored by many shops - getting rid of old features that are unused.  Old hardware, obsoleted features, invalidated combinations, all of these lurk in many (most?) applications, waiting to spring on the unwary.  But I rarely see mention of this pruning in the literature - refactoring gets mentioned as a response to changing requirements, but the requirements-gathering always gets described from the viewpoint of a new project, not a mature product.

One of the hard parts is that it's often impossible to determine which features are no  longer valid, because the reasons for them in the first place are lost in the mists of time (or Bob, the original architect, retired 2 years ago, and is sipping Corona on the beach at Cozumel).  So I was thinking that it would be a cool feature of an advanced source code management system to tag a set of changes with an expiration/re-examination date, so that the developers would be reminded of the need to do this, and contain the explanation of the feature so that this later validity could be checked.

---