"Code Salvaging" and the Surprise Costs!

Being VP, of Development at Blueprint has given me the opportunity to interact with a wide array of successful businesses and their key players. One question I encounter time and time again during initial scope meetings is, “Can you salvage my code?”

This questions almost always occurs because their project failed to be delivered by a previous development company or developer(s) and our client is now stuck with paid unfinished code. My response is always the same, “We can certainly take a look to see what we can do, but it’s almost always cheaper and faster to start over.” Although the answer seems dismissive, it comes from a complex foundation of reasons.

Code Theory

Code is purely logic. Everyone thinks differently, therefore codes differently. This makes perfect sense to any developer or programmer. For the less tech savvy individuals, the easiest analogy to explain this is to start with a questions. Using only math, how many ways can you get to the number 20? This might sound like a silly question, but it’s directly related to coding. Below is a list of 3 out of an infinite amount of ways to mathematically accomplish arriving at the number 20.

1. 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 = 20
2. 1 + 9 + 10 = 20
3. 1 * 20 = 20

While each example shows the same end result, their methodologies differ dramatically. Let’s take example number 1. Adding the number 1 twenty times will arrive at number 20 by using 20 unique cycles of addition. Although the same answer, example 2 only uses 3 cycles to arrive at 20 and example 3 only uses 1 cycle. Of the 3 examples, example 3 is the most efficient way to “code”. Code efficiency is one major reason why starting over can be more cost effective. When trying to append or modify inefficient code, developers often find themselves solving 1 issue, while creating 2 more, opening a “black hole” of indefinite billable hours.

Incompatible Code

Another surprise cost to “code salvaging” is compatibility. Most commonly seen when multiple parties are working on different components of the same project, one module may have been built in .NET while another may have been build on JSP, PHP or another language. To relate this to my mathematical example, let’s pretend Bob and Sally are writing two halves of an algebraic formula to arrive at 20.

Bob writes variable a = 2 * 2
Sally writes variable b = 10 + 6

The project requires the combination of a & b to equal 20. If we add variable a (which equals 4) and variable b (which equals to 16) the answer is 20. To demonstrate compatibility issues, the server handling the project once fully assembled can only adds and cannot multiply. When combining variables a & b with this newly found issue, the answer is no longer 20 as it cannot be processed.

Surprise Costs

Code salvaging assigns the new developer the task of opening thousands of lines of code (depending on the size of your project), reverse engineering the logic another developers logic, rewriting any efficiencies while converting incompatibilities. Although there are many reasons to discourage “code salvaging”, the main reason at Blueprint is its almost always cheaper for our clients to start over with custom development. The summary is, code salvaging can be a “can of worms” full of expensive surprises.