I'm having some difficulty to evaluate the revision of a software: the software was paid by customer years ago, never used, and now the customer have noticed that it doesn't work as expected.

Now this customer asked me to evaluate the project (I have the sources), and I should give an estimation of the time to fix it and probably a maintenance contract.

However, after having analysed the code all the day, I notice that the source code base is very bad. Here is the crucial characteristics:

  • A lot of source lines (140K+)
  • C++ without classes, all statically allocated, all externs, all public
  • Poor comments, poor documentation
  • A bunch of warnings, counted more than 7K+ times. Warnings spreads from unsigned/signed mismatch to aliased variables, till uninitialized variables.
  • Static analysis tools have signaled buffer overflows, unassigned variables, suspect string operations.
  • Lot of multithreading and no critical section at all.

The code will compile, but only the "debug" version is able to run for a short time. I suspect that buffer overflows are working enough.

I've already encountered code like this, I'm not surprised that it is not working as expected. Now I'm thinking how to face this task in the most convenient way, and this is what I thought:

  • Fix all compiler warnings.
  • Fix all static analysis warnings
  • Ensure exclusive access to data shared across multiple threads
  • Enable _HAS_ITERATOR_DEBUGGING for debugging std::vector accesses (vector is used a lot). This imply an upgrade to VS 2005, at least.
  • Uses CRT heap debugging as much as possible, even if this imply to move most of the global variables to be allocated on the heap.
  • Extensive use of assertions (along with minidump creationg for post-mortem analysis)
  • Exhaustive test cases to prove/test software robustness.

I would like to prepare unit testing, but I should refactor methods with 2500+ lines, and it would add enough pain to give up.

I think I have a good plan, or maybe I'm only in the right direction. I think I'm missing a measurement to actually evaluate the work I could face. Any thoughts?

  • it's cheaper to start from scratch with a good sight on the requirements than to "fix" this mess Apr 2, 2013 at 22:48

3 Answers 3


There is no way for us to answer this, other than to say that you are being tasked to perform something impossible, and to run as far away as possible!

Okay, that is a bit unfair, but some things just cannot be known/estimated. The only way you can give an estimate that has any chance of being vaguely related to the truth is to work with the code and understand it. We are talking weeks to months. I doubt you are being paid for this estimation effort; it sounds like you are bidding for a job. So, your business depends on what will amount to a total guess.

I would tell the person that it cannot be estimated without weeks of work. Your general workflow sounds not bad, and so just suggest that you do this for a month, and at time you will regroup. Note there is no promise that you will have a better estimate on the amount of work - that too is unknowable. At some point it will become clear whether it makes more sense to keep pouring money into this code, or start from scratch, or just abandon the whole idea.

With that said, I think the post about this being "dead code" is 100% accurate. I cannot estimate how much it would cost to iteratively transform a beat up mobile home into a 35 room mansion, but I can tell you that it would be cheaper to just raze the thing and start from scratch. You don't need to estimate the magnitude of a money sink.

  • 2
    Good suggestion - when the magnitude of a task cannot be estimated without a serious investment of effort, it is absolutely appropriate to quote the client a price for the investigative effort. Quote them for an amount of work (a week, a month, whatever) and state that at the end of that they will have an amount of cleanup work done, they will have a review of what remains to be done and the state of the code, and they will have a quote to complete the work (which may well be larger than the expense of a rewrite-from-scratch). Apr 2, 2013 at 22:22

You are describing dead code. If it hasn't been used for years, it never worked, and the customer's needs at the time it was written are not the same as the customer's needs today. Broken, untested, unmaintainable code will never meet your customer's needs and you will go through more pain, and your customer through much greater expense (not to mention risk of failure) by trying to scavenge something useful from the existing code base than by starting fresh, with a minimum viable product that your customer can start using soon and giving you feedback on.

  • The customer needs are not changed. I could consider a "from scratch" solution: probably I will produce a more concise solution; but I need to compare costs of the two solutions: while I can plan/evaluate my development, how I do with other's code?
    – Luca
    Apr 2, 2013 at 20:25
  • 7
    I can't imagine that it will be economically feasible to fix 140k+ lines of someone else's poorly architected, poorly documented, poorly commented code which is rife with such notoriously difficult bugs as race conditions in multithreaded code. Apr 2, 2013 at 20:26
  • 1
    It might be hard to convince your customer of this, but it's absolutely correct.
    – huntmaster
    Apr 2, 2013 at 22:04

Take the time it would take you to build a system like this from scratch and then multiply it by a factor of ten. That might adequately capture the average-case complexity even if it doesn't adequately assess all the risks.

This is about as good an example as I can conceive of for when not to do the Big Rewrite. Whatever the true level of effort is, it's way beyond any reasonable threshold for feasibility.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.