One of the things I like less about programming is maintaining the code-base of old projects. You know what I’m talking about, right? coming back after several months or even years to a code-base requires a certain adjustment period as you try to recall why you made this and that decision and stumbling across some old hacks that helped the project complete at the time, but make you cringe when you consider you might need to make changes now.
Even if you are an extremely disciplined developer, always refactoring and trying to get your code-base in the best shape possible, old code-bases will leave you wanting. If you are like me, and try to improve between each project, it always seems like the practices you used in older projects are now outdated. Your first inclination might be to just scrape everything you’ve previously done and start from scratch, trying to build the best solution you can with your current skills and knowledge.
But hold on for a minute and bear with me – you actually want to reuse code from older projects. And here’s why:
Saving time and shipping products
The difference is subtle, but we’re in the business of shipping software products – not developing it. What does that mean? it means that recreating a code-base for the sake of using the latest techniques in your arsenal might seem like a good idea but it really isn’t unless it solves some tangible business needs, such as improving performance when it’s needed or reducing the overall time spent working on the project.
One of the biggest optimizations we can make in the development of a software products is how we make use of our time. The more efficient we are with the use of our time, the better chance the project has of succeeding. No project has a perfect schedule and setbacks can always occur and make a project can go off the rails through time loss.
One of the best ways to optimize your time working on a project is leveraging code you already wrote. The bigger problem the old code-base solves, the more time you save by reusing it.
Increasing stability and reducing bugs
One of the most overlooked aspects of code-bases of previous successful projects is that they usually have been used by real users and thus have received quite a bit of real-world quality assurance. Those hacks that made you cringe when you went over your old code? they might actually resolve some edge-case bugs that took a lot of time to catch.
When you reuse a code-base that has been through the grinder you can have much more faith in its stability and you can be certain you will find much less bugs than if you developed it again from scratch. This is one of the reasons many projects opt to integrate 3rd party solutions (commercial or open-source) that have a large user base – they are generally much more reliable and stable than newly (/internally) developed products.
The more code you write the more bugs you introduce. Keeping this in mind, it’s easy to see how reusing old code that has been thoroughly tested already will reduce the amount of bugs in your project.
Once you’ve solved the same problem in several projects, the benefits of having a standard solution becomes obvious. If it seems like future projects will need to solve the same problem, it might be a good investment of time to extract the current solution, clean it up and preparing an easy to integrate standalone component.
A small investment of time now could save you a lot of time in the future for the reasons already mentioned. The time investment in cleaning up old code for reuse is sometimes a compromise between writing it from scratch (a big time sink) and using code that is not up to par with the rest of the project.
But there is actually another aspect to it that might not be readily apparent – creating a standalone product.
Parts of your code as standalone products?
Something completely unexpected might have just happened – by extracting some old code and polishing it for reuse in current projects, you might have actually created a new, standalone product. It’s easy to overlook this aspect with your eyes on the goal – the completion of the project at hand – but you might have another ready product on your hands and you didn’t even know it.
Your time spent and experience gained developing an old code-base has value. The bugs squashed and issues resolved through real-world use increase that value. The combination of those elements could result in a standalone product that might benefit you in the future, or better yet, benefit others as a commercial or open-source standalone product.
This last point is a big part of the reason we started Binpress – to promote the practice of reusing and putting code in the public domain, in either open-source or commercial formats, to reduce the time spent developing solutions to problems already solved and increasing the chance of success for as many software projects as possible.
Have I convinced you that reusing code from old projects is worth your time? I would love to hear your thoughts in the comments!Binpress Open-Source