The document discusses the benefits of static code analysis tools, particularly PVS-Studio, in identifying defects in C++ programs and the return on investment (ROI) they offer. It argues that integrating such tools can significantly reduce the time and cost associated with fixing bugs, with estimates suggesting financial savings that far exceed the cost of the software. The analysis concludes that using a static analyzer like PVS-Studio can lead to substantial annual profits by decreasing the hours a programming team spends on addressing errors.

1. Static analysis and ROI
Author: Andrey Karpov
Date: 06.06.2011
I regularly communicate with potential users who are worried about errors in C++ programs. Their worry
is expressed in the following way: they try the PVS-Studio tool and start to write that it finds too few
errors during tests. And although we feel that they find the tool interesting, still they their reaction is
quite skeptical.
Then a discussion starts where I try to convince them that PVS-Studio is a very good and useful product
and that it could be very profitable to their company. In response they criticize my explanations and
make caustic remarks on the analyzer's work and false alarms it produces. Usual marketing work it is.
While communicating with one of these users I wrote a detailed answer and my opponent suggested
that I arrange it as an article. And this is what I am doing. We are waiting for your comments on the
estimate of a profit static code analysis tools may bring. Although I wrote the article keeping PVS-Studio
in mind, the calculations given in it seem to be interesting regardless of what static analysis tool is under
discussion.
The text cited below is an answer to the following fragment of a letter:
...
About 40 (forty) more real defects have been found - in most cases, this is a bad copy-paste.
The question is: what will we get from integration of an expensive program into the process of
developing a software product in code of which the program detects so few defects? Yes, I understand
that we will find a fresh error quicker, but there are not so many fresh errors.
...
So, let's have a look at static analysis tools from the viewpoint of ROI.
Let's take an average programmer who spends most of his working time on developing C++ software. It
is easy for me to imagine such a person since I myself have been programming a lot for a long time.
Suppose that he runs a static code analyzer at night. Also suppose that the analyzer, being used in this
working mode and at a medium programming rate, can find two defects in code made by the
programmer in a week.
This is not abstract reasoning - I tell this relying on my own experience. I am handling the code only with
half of usual effort now but almost every week I notice a mistake in my own code thanks to night
analysis. Usually it is some trifle that would reveal itself when writing a test or running regression tests
but sometimes I find really serious things. Here is a sample of a defect PVS-Studio has found in my own
code quite recently:

2. bool staticSpecification = IsStaticSpecification(sspec);
bool virtualSpecification = IsVirtualSpecification(sspec);
bool externSpecification = IsVirtualSpecification(sspec);
The fact that I write articles about the harm Copy-Paste does in no way prevents myself from making
such mistakes. I am human too and I copy code fragments and make mistakes too. It is very difficult to
catch an error like the one shown above. In practice it would cause the analyzer to generate a false
alarm on some code constructs in certain cases. I would hardly manage to create a manual test for such
a rare situation (to be exact, I did fail to create this test since I had put this code into SVN). What is
insidious about this error is that if some user complained about it, I would have to search for it at least
for a couple of hours and also ask the user to send me the *.i file. But let's not get distracted.
If the programmer writes code more regularly than me, 2 real warnings generated by the analyzer
during a week is a natural quantity. Altogether the analyzer can produce 2*4*11 = 88 actual warnings
during a year. We could neglect the time needed to fix such defects and suppress false alarms. But still
let's take it into account.
Suppose the programmer spends 20 minutes in a week to fix 2 real errors and 2 false alarms. Altogether
he will spend 20*4*11 = 880 minutes in a year on handling the analyzer. In other words, it is 15 hours.
Does it seem a large waste of time? It is very little in comparison to what we will calculate further.
Now let's consider the price of eliminating the same defects in case the analyzer does not detect them
during night tests.
The programmer will find 60% of these errors himself a bit later while writing unit-tests, during
individual preliminary testing or the process of debugging other code fragments. Let's say that the
search of an error itself and fixing it will take about 15 minutes in this case since the person is handling a
recently written code and knows it well. For example, the programmer might find a text in some
dialogue that should not be there and find out that yesterday he used x.empty() instead of x.clear() by
accidence:
url_.empty();
if (status_text)
url_ = status_text;
And do not tell me that fixing such errors takes only 1-2 minutes. A correction itself takes several
seconds at all. But you have to find the necessary fragment, compile the fixed code, check if your
correction is right and probably introduce corrections into SVN. So let's say it's 15 minutes.
I would like to note right away that errors of this kind are usually fixed by programmers mechanically
and are not considered errors usually because they are not recorded anywhere.
35% of errors will be found at the testing stage. These errors have a longer life cycle. In the beginning, a
tester locates and recalls an issue. Then he makes a description of the error and places it into the bug-

3. tracker. The programmer finds and fixes the error and asks the tester to check this fragment once again
and close the error. The total time spent by the tester and programmer together is about 2 hours. Here
you are an example of such an error: incorrect handling of OPENFILENAME. The programmer might be
lucky and he will not see the rubbish in the dialogue while the tester will, yet not every time
(Heisenbug):
OPENFILENAME info = {0};
...
info.lpstrFilter = L"*.txt";
We have 5% of errors left unnoticed. That is, programmers and QA-engineers cannot find them but a
static code analyzer can.
If you take your current project and check it with PVS-Studio or some other static analyzer, you will see
that very unnoticed 5% of errors. This 5% is those very 40 errors the potential user has mentioned while
trying PVS-Studio.
The rest 95% of errors were fixed by yourself earlier while writing tests, using unit-testing, manual
testing and other methods.
So, we have 5% of errors we cannot find and they are hidden in the product we are releasing. 4% of
them might never occur at all and we may ignore them. The remaining 1% of errors might reveal itself
unexpectedly by the user's side and cause him a lot of troubles. For instance, a client wants to write a
plugin to your system and the program crashes because of this code:
bool ChromeFrameNPAPI::Invoke(...)
{
ChromeFrameNPAPI* plugin_instance =
ChromeFrameInstanceFromNPObject(header);
if (!plugin_instance && (plugin_instance->automation_client_.get()))
return false;
You never do that and always check external interfaces? Good guys. But Google Chromium failed here.
So never make such promises.
If you value your client, you will have to spend many hours on finding the defect and corresponding with
the client. After that you will have to additionally make a fix for him or release the next version ahead of
time. You might easily spend 40 hours of working time of various people (not to speak of their nerves)
on such errors.
What? Who said it's not true? You have never wasted a whole week on one insidious bug? Then you
have never been a true programmer. :)

4. Let's calculate how much time we could save during a year:
88 * 0.60 * 15 = 792 minutes
88 * 0.35 * 120 = 3696 minutes
88 * 0.01 * 40 * 60 = 2212 minutes
Altogether the programmer spends (792 + 3696 + 2212) / 60 = 112 hours during one year to fix some
subset of his own errors.
A team of 5 persons will spend about 560 hours or 70 days during a year on their own mistakes. Taking
into account paid weekends, vacations and sick-leaves we can say it is about 4 months of work for some
abstract person.
If it is profitable to use a static analyzer or not depends upon the salary of your employees.
Since we speak about some abstract person (not only programmers are participating), let's take a salary
of $6000 per month. Taking into account salary taxes, rent, computer purchase and depreciation,
bonuses, Internet, juice, etc., we can easily increase this number twice at least.
So we get that the price of fixing errors (not all errors, but most of them) without using static analysis is
$ 12 000 * 4 = $ 48 000.
If we find the same errors quickly using static code analysis, the price of fixing them will be 5 * (15 / 8) *
$ 12 000 / 20 = $ 5 600.
Let's add the price of purchasing the PVS-Studio license for a team of 5 persons to this figure.
The final price of fixing errors using a static analyzer will be (3 500 EUR) * 1.4 + 5600 = $ 10 500.
Altogether the pure annual PROFIT from using the PVS-Studio static analyzer in a team of 5
programmers is:
$ 48 000 - $ 10 500 = $ 37 500.
The price of fixing some errors has decreased more than three times. It's up to you to think and decide if
you should have this or not...
Yes, I also would like to note that I proceeded from rather conservative figures in my estimates. Actually
I think that investments will be repaid much better. I just wanted to show you that you will get profit

5. even at the most conservative estimates. And please do not try to reproach me for any figures saying
that they are false. The article shows an approach to a quality profit estimate, not a quantitative one.