Our application is a 6-year old legacy application made by out-of-house contractors. Occasionally we stumble upon the skeleton of something they put together but never implemented, and it causes us to stumble as we try to figure out how it's used in the app.

One of these classes seems like it might be close to what I need for a certain change I've been working on, but large parts of the implementation are missing, and it's not clear at all how it's meant to connect to other parts of the app - meanwhile, there's several functional parts that I could easily pull from and put together to create all new classes for the purpose I'm looking for, and it would have a more accurate name and be re-usable later in app development.

But I also know that it's considered 'best practice' to re-use code whenever possible, and I don't want to be responsible for putting together something entirely new when something else is sitting right there, waiting to be used.

I've spent about half a day trying to implement the old code, and I'm starting to think the skeleton is so incomplete that it'd just be easier to put together new methodology on my own.

So, the short of the question is - when faced with a problem where a solution is present but incomplete, is it better to implement old code that's incomplete, or write your own?

  • If is it a skeleton that remains incomplet. Can we say that there's no code to reuse at all?. Is this skeleton somehow a modelized 'concept' of something what was never made? Or it actualy works 50%? – Laiv May 13 '16 at 19:29
  • Does it mean if you do not extend the existing class and start to write your own, you will have to copy some of the already working parts in it to a new class, leaving you with duplicate code? – Doc Brown May 13 '16 at 19:32
  • @DocBrown More that I know there are parts of the code elsewhere in the app that do a similar function - but not exactly what I need them to do, and not at all in a place where it's useful to me. It is, sadly, quite a mess, and easily the messiest part of our application as a whole. – Zibbobz May 13 '16 at 19:43
  • This answer of mine has a chart that could help you decide: programmers.stackexchange.com/a/161912/61852 – Tulains Córdova May 13 '16 at 20:08
  • You may have figured-out what the code does, but if you don't know why it does it, reusing it can get tricky if it needs to be changed. – JeffO May 16 '16 at 8:34

Reusing code is not about resurrecting old unused and abandoned code and putting it to use. Reusing code is about making the same code fulfill multiple purposes (perhaps within the same project) by providing a useful abstraction that can be (re)applied in other contexts.

Old abandoned code may be consulted, but should probably not be resurrected. It should be viewed suspiciously, with regard to being stale (relative to design changes within the now current code) and also being obviously untested.

The biggest expense in development is not necessarily writing the lines of code, but knowing what code to write (to address current needs). Old unused and abandoned code likely will not show you that unless for some reason it turns out to have been exactly what you needed.

So, I think you're better off writing your new functionality as new code, though you should refactor in-use existing code (not the old unused code) as needed to make more universally applicable abstractions to make adding new functionality easier.

  • 1
    The biggest expense in development is not necessarily writing the lines code, but knowing what code to write So great phrase :-) – Laiv May 13 '16 at 20:00
  • 3
    Also, banish the skeleton code from the code base. Vestigial code is just a liability. – MetaFight May 14 '16 at 0:38
  • 1
    @MetaFight, totally agree; given source code control there's no reason to keep unused code, even if commented out! – Erik Eidt May 14 '16 at 0:48

I will share with you the point of view that an architect of my company shared with me.

If the cost (in time) of to review code, to understand what it does, to test it, to fix it (in your case to complet it) and to integrate is more expensive than to do it from scratch, then start from scratch

As Erik pointed you should not trust in code that (as you mentioned) doesn't make you feel confortable or confidence enough.

If you look at code it may seems reusable. May be part of it. But look at it with perspective. Does the global solution fit in your requirements? Is the solution (half-coded) reusable?

Good designed code often ofers a reusable solution to the same problem.

However tailored code, in the conditions you have exposed is closer to be rejected than to be reused or resurected as Erik said.

It doesn't mean you can not take ideas from what it's done. We here call them borrowed ideas. You can follow the same strategy in your own code, making it suitable for your needs, rather than manipulate something which goal seems unclear.


You don't reuse code whenever possible. You reuse code when reusing the code is more beneficial to you than writing new code.

It looks like the most efficient way to handle this is to design everything properly, especially if you think that you need code doing several very similar but not identical things, and then when you implement the code, scavenge what you can and what's worth it from the carcass of the existing code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.