Avoiding cruft when design catches up with implementation

Question

I'm a contractor and am often brought in on projects to be heads down and just implement features for a deadline. Oftentimes though my pace becomes faster than that of the underlying design. So I often wind up having to create functions/methods to perform a task in a preliminary way while awaiting the final design.

Case in point, currently I was tasked with performing the default sort of some records in a way that is too complicated for the current database design (actually I'd use MySQL's "field" function, except I don't think Java/Hibernate supports it). So I created a function where the records could for the time being be sorted at the application level, that could either be re-implemented, or entirely avoided, once the necessary database design work is done.

My concern is, once all the necessary design is finished (in general and/or specifically as regards the scenario outlined above), I don't want to leave behind a trail of possibly unnecessary functions/methods. Sometimes they might add value to the design, but sometimes they may wind up being an unnecessary layer of indirection in the end.

How concerned should I be about this? What can I do to mitigate this? Typically being a very short term contractor, I usually don't have the time -- or authority -- to implement something such as a "strategy pattern", which might be my inclination if I were actually responsible for the overall design.

Answer 1

I think a certain amount of cruft is to be expected as a code base evolves. Even when you try to be systematic about deleting away old unused code it is hard to remove it all. It's always satisfying to find unused code in my system that I can delete.

Strong typing is your friend here, since it allows you to track types and usages in a much better fashion than weak typing. So stay away from those string data types, they make cleaning up harder.

A really neat trick is if you can replay 24 hours worth of traffic from your production systems over a test system with a code coverage tool running at the same time. That's usually a gold-mine of dead code, but it can be hard to find the time to deal with such large amounts of cleanup among other priorities ;)