Software developers love writing new code. There’s something thrilling and exciting about designing creative, efficient solutions to new problems. Given the chance, many would rather write something new than reuse existing code, but despite what developers want, rewriting an entire codebase is not always good for business.
At the other end of the spectrum, most business executives want to see prototypes and give demos of new products as soon as possible — and often sooner! Writing new code is slow, but reusing code can be fast. Stitching together functionality from existing in-house software or an open source software project can help create working prototypes in a matter of weeks or months depending on complexity.
As a project manager, how do you strike a balance between new, elegant, and efficient solutions that your developers will love creating, on the one hand, and your business development group wanting a prototype tomorrow, on the other? It’s true that starting from existing code will jumpstart development, but before giving in to that temptation, there are a number of considerations that could prove costly down the line if overlooked.
Contents
1. How much of your problem does reuse solve?
When evaluating any codebase for potential reuse, estimate how much of your problem it actually solves. It’s unlikely the existing code forms a complete solution to your problem, or else you wouldn’t be writing new software at all. With that in mind, it’s important to identify areas where your needs are dramatically different from what’s provided. If the existing code falls short of what you need, your team will need to extend the capabilities. Alternatively, maybe you need only a small subset of the functionality provided. Should you ignore the additional capability, in case you grow into it later, or should you try to remove it, to reduce complexity? Both options can be valid depending on the situation.
2. How much flexibility do you need?
Well-defined requirements specified at the beginning of the project are great in theory, but reality is always different: feature changes inevitably creep in throughout the development phase. Try to gauge the level of effort involved in adding potential features to a codebase that your team did not write. Sometimes customers and marketing groups are willing to discuss various options for achieving the same goal, but other times, you may have to force changes in places where they don’t naturally fit. It can be much easier to bend your own code to your will than to bend someone else’s.
3. What does the existing code look like?
Code can run the gamut from utterly incomprehensible, to reasonably well written, to almost a work of art. Most likely, the code you’re evaluating falls somewhere in the middle of that scale. Differences in indentation and formatting can be overlooked as a minor irritation, but it’s nearly impossible to reuse code when all the variables start with the letter “i” (i, i1, i2, ii, iii, i_3, and so on).
Related to code readability is code complexity. There is some beautifully written code that is so “reusable” that it’s extremely difficult to understand. Making things generic can lead to complicated logic that is unnecessary for a specific task.
Your willingness to put up with less-readable or less-understandable code will depend on the previous two considerations. If your team will be making dramatic modifications, consider how hard it will be for them to modify and maintain the code you’re evaluating. For cases when the code is poorly written and poorly documented, and it only solves part of your problem, it might be best to start from scratch.
4. Do you have to deliver the code?
If the software you are hoping to re-use was developed under the GPL or similar license, then you will have to make available the source for the modified GPL code plus any modules linked to it. Depending on your business requirements, releasing your code may or may not be a problem for you.
If you’d like to re-use GPL code but not release all of your product’s source code, there is a possible alternate approach. The GPL restriction only applies to the executable that modifies or links against the GPL’ed code. If you can isolate that functionality in its own executable that communicates to the rest of your software using various IPC mechanisms, you can insulate most of your code from this restriction. You may be content to give away the custom wrapper code if it means you can use the capabilities of the existing codebase. This amounts to trading possibly a month’s worth of development in exchange for several months’ worth. However, this option comes at the cost of added complexity because you have to synchronize and provide communication between separate executables.
Every project has different motivating forces, but all of them are tied to a deadline. Reusing existing software to shorten that timetable can be appealing during the planning phases, but saving time in the beginning can sometimes prove costly in the end when it counts most. Careful consideration of the issues involved in reuse can avoid or at least identify these potential problems — while there’s still time to plan accordingly.