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_DEBUGGINGfor debuggingstd::vectoraccesses (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?
1
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.
1
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.
3
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.