Is it better to try and implement incomplete code, or write your own?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.