You heard that right. When is it right to not reuse good code?

  1. Not Homegrown
  2. Not Neat
  3. Not Extensibly Tested
  4. Not Production Code
  5. Not Familiar technology
  6. Not Extensible
  7. Not Modular
  8. Not reusable

Would you have any problems in reusing code which does not fit any of these criteria? What if the code to be reused is not of the same architecture ? Is that reason enough to not use working, deployed shipping code, for another program?

You be the judge of that. Here are the factors that come into play –


A new product, based on C++ and a central database architecture. The code to be reused/not, is written in Java and writes all of its data into flat files.

Ways in which reusing the old code base is beneficial

  1. Core logic is working (past 5 years) + has all the characteristics of good code listed initially.
  2. Popular wisdom of saving years of grease and hard work(In this case 3 years worth)
  3. Not using the central DB reduces the load & leaves room for future growth.
    1. Central DB is expected to be squeezed further if new data comes in now. Load expected is not crippling but large enough to make a difference if avoided.T
    2. There might be optimizations or atleast investigations required on how to avoid this. 10-15 days will be lost in identifying the optimizations required. But rest assured things will fit in. Has to.
  4. There is no risk in terms of will old code base and its modifications work. It will work.
  5. With Java its hard to shoot yourself in foot with memory corruption.

Factors hindering the reuse(ascending order)

  1. Can only run as a separate process.
    1. New code for required inter-process communication
    2. New code required for installation & start stop management of the process.
    3. New code has to be written to make reports from flat file.
    4. New code for flat file roll up functionality.
  2. The Java process puts all its data in flat file. So report for this set of data alone become harder to develop.
  3. Old code base has to be fairly modified to cut it loose from its other dependencies
    1. The effort in code modification is almost half the effort of reusing the old module. Some times it easier to just rewrite than modify. However years of intelligence built into the code comes with reuse
  4. Reusing the old code dilutes the architecture, has an apple cart upsetting effect.
    1. Central DB is no longer central in nature
    2. The architecture is now free for all and can grow in weird size and shapes going forward. This might set a bad precedent for future expansions.
  5. No major value add is done in the reuse scenario
    1. No major new code base / technology framework is developed from this effort
    2. No new knowledge is gained.
  6. Optimizations of small nature (not measured yet) might be possible with new code.
    1. Opportunities to do this seems available. The exact nature of the improvements are not clear. But there are some. Chance to avail of this seems to be lost when reused.
  7. Having an external proc that does things differently could have ramifications later on.This might introduces un-necessary rigidity overall for the growth of the
    program later. However it is not truly clear how things can progress.
  8. There will be duplication of functionality between the existing code base and the old code base about to be reused. The amount of duplicate code in the system will suddenly increase across the different sub-systems.
  9. Overall, it adds complexity to the system.
  10. The issue is not about rewriting a part of an existing product or an entire product which is almost always a strategic mistake, but about whether to reuse or not. Common / popular wisdom about rewriting / not does not seem to make too much of a difference in this case, in the long term.

The development time we are talking about is 66 days in case of old code vs 110 in case of new code. One can also assume the old code to be 80% less buggier during test phase but this might not be a real advantage since there are other stuff going on, which could effectively block the program, such that this time saved during testing is not really reflected. However add 15 days extra for new code for good measure.

Totally Time comparisons

Old code total = 66 + test time?
New code total = 125.

So what gets your vote?

Reuse with modifications or rewrite? Would you rewrite a family code essentially to keep up with the new architecture. Is conforming to the overall architecture that important?

My take on it – lets write new code. Why ? The effect on architectural consistency and the lost opportunity in improving things. I love being creative and as long as there is budget i would want to do so, as long as it brings value. But the tipping factor in favor of new code is the fact that no one wants to vouch for things either way and proponents of reuse themselves are not so sure or do not want to make a call and be responsible. So for me, the way forwards automatically becomes writing new code.

The reason I’m blogging this is to demonstrate the absurdity of the situation and the nature of decisions that are to be made in the industry. All the members of the team are fairly experienced, (6-9-14 years) and the manager even more so. Most of the team members already manage this existing code and are intimately familiar with its construction and are sure of its solidity. Still no one can say for sure the way to go (i suspect the reason to an extend being the fear of taking up the responsibility) The major factors that helps make the decisions are soft in nature (and hence the confusion) and the factor that tips the decision turns out to be not in anyway technical at all. And its not just us who has this confusion either. Everyone out there, even the big-wigs seems to be arguing back and forth about this same issue over and over again.

Constructing software is rarely about the tools or technology in the same way winning a war is not about better swordsmanship. It has to do more with the human factor and good judgment about what can work and what might lead to other issues. This again is subjective to the situation and the people involved, which is why software is god damn hard to get right.