Our website uses cookies to enhance your browsing experience.
Today we had a conversation with Evgeniy Ryzhkov, CEO of the "Program Verification Systems" company developing software products in the area of software testing systems and static code analysis systems. The company currently offers two products, PVS-Studio and a recently released CppCat. Both are static analyzers for C++ code.
Unfortunately, we are no longer developing or supporting the CppCat static code analyzer. Please read here for details.
This article was originally published [RU] (in Russian) at the website siliconrus.com. It is an interview with Evgeniy Ryzhkov by an author and editor at siliconrus.com, Konstantin Panphilov. The article was translated and published at our blog by the editors' permission.
Picture 1 - Evgeniy Ryzhkov
In this interview, we have discussed specifics of debugging, problems of running an international business in Tula, issues of the pricing policy in their area, and cats.
Panphilov: Hello! Tell us please about your business in general - what are you doing, why, and who else takes part in it?
Ryzhkov: I work at the "Program Verification Systems" company which we founded together with my associate and business partner Andrey Karpov. We are situated in a provincial city of Tula which is famous for its arms industry, samovars, and traditional pryanik gingerbread. Since all these fields are already occupied, we've chosen an area which is not very usual for Russia. We develop programmers' tools. To be more exact, we create static analysis tools for C++ code.
Currently our team consists of six people, but, despite the small size, we manage to create pretty cool and complex stuff. I mean first of all the PVS-Studio analyzer and our new product CppCat, which is a greatly revised version of PVS-Studio with a different pricing and licensing policy.
Picture 2 - Andrey Karpov, cofounder
Ours is a most typical software company: we create software products and sell them to customers. In this sense, we are not quite "in the trend": we don't design mobile applications with millions of installs, or possess a website with hundreds of thousands of unique visitors. We run a, so to say, classic business which seems to be pretty rare nowadays.
All the work on promoting, advertising and selling our primary product, PVS-Studio, we do on our own - not to mention that we develop it on our own too, of course.
KP: What is the difference between CppCat and PVS-Studio?
ER: First of all, PVS-Studio is a pretty expensive and strongly specialized product. The cheapest license - the one for a team of up to 9 developers - currently costs €5250. Besides, this is a product with a long history (it was introduced in the beginning of 2011) and it has by now accumulated a lot of features which not all developers need. That's why, in the autumn 2013, we decided to redesign our product as if we were developing it from scratch.
It took us 3.5 months to develop and release such new product (based on the existing one, of course). We got it clear of all the stuff that we found inconvenient and complicated, and worked out a new pricing policy. We offer single-user licenses for the product at $250. The tool was launched soon after the New Year. And you know, we were much astonished ourselves at having managed it all in just 3.5 months. By the way, I have a nice story to tell you about how its name was conceived.
Picture 3 - A recreation room in the office. It's empty - right, no time for relaxation!
You know, inventing names is a very difficult task. Those who have ever had to do it know what I mean, and those who haven't perhaps won't believe me. Anyway, we needed a name that met a few requirements: 1) it should emphasize that the tool was designed for C++ programmers; 2) it should be vacant (that's why various names like cppcheck and codescan wouldn't do); 3) it should be amusing; 4) it could be illustrated by a nice logo.
Well, there is a general belief that programmers are fond of cats, and we used it as an inspiration source. If you visit the Cppcat website, you'll see our logo hanging there all about (just scroll down a bit). So, it took us two weeks out of 3.5 months to make up the name and about a month to design the logos and test them on focus groups.
Picture 4 - This is how CppCat was being born
KP: You're offering PVS-Studio at such a high price - are there really any customers? Is it that Visual Studio's standard debugger is so awfully bad?
ER: Well, 85% of all the purchases are made from the US and Europe, while Russia makes only 10% of our sales. Static analysis tools are commonly pretty expensive throughout the world. You can't have thousands of customers, so you have to set high prices. It is not that Visual Studio's debugger is bad. Let me explain the way a customer makes a decision about using our or any other static analysis tool. He runs the trial version and studies the bugs it has found. If he finds really interesting and worthy issues, he estimates how much time it would have taken a programmer to find and fix those bugs manually. Then he estimates the cost of an hour of work. If he finds that the tool can help save time on bug search, he will buy it. And here we face a few issues with sales, and I'd like to tell you about them.
First, when studying and evaluating a tool, the programmer may fail to find interesting messages among the issues detected by the analyzer. It's not because the tool has not found errors. It's that when you get, say, 300 messages, you will be most attentive when studying the first 10. You will be less attentive when studying the next 20. And then you will stop right there. So it is very important that the most interesting messages should be shown in the beginning of the list.
Second, the cost of one hour of work I've already mentioned. If it is low (for example, in a project where students are engaged), the customer certainly doesn't need a static analyzer. But when you deal with highly-paid American programmers, who earn $50 per hour, a tool that can help to save at least some time would be useful.
Picture 5- One more photo of the office: a shaman's drum - a gift from Intel. A crucial part of a debugging ritual.
Third, static analysis tools allow users to detect bugs in the code right in the middle of writing it, before it gets to testers who, in turn, will need some time for testing it and forming a bug report - and all that bureaucratic stuff accompanying the whole procedure. No need to say when it slips over to the users.
However, those who are not familiar with the static analysis technology may mistakenly think of it as a wonderful miracle - so why are there still bugs in programs when we have such a powerful weapon? Of course, it's not all that cool and neat. It's just an ordinary technology with its own advantages and disadvantages. Some find it useful, and some others do not.
By the way, the specific character of our target audience sets some interesting limitations on the ways of product promotion.
KP: Yes, that's interesting too, but before that I'd like you to tell us how you managed to launch your business so quickly.
ER: Well, I'm afraid our start was not so quick. We founded our company in 2008 - it was then that we started working with static code analysis technologies. Our first product named Viva64 was designed for finding issues of software migration to 64-bit systems. By the way, detection of the issues in migration to 64-bit systems was my graduation thesis subject, so our product was evolving along with our scientific work. And my coworker Andrey Karpov was working on his own thesis on parallel programming. Naturally, we had jobs as programmers but wished to try something of our own. That was how Viva64 appeared. Unfortunately, we were not that experienced in selling our products as we are now. For a long time, the tool didn't bring us enough profit to found a self-managed business and drop working as outsourcers to earn our living.
Picture 6 - It is usually recommended to nail a horseshoe to the computer's chassis... Why is it on the wall then?
Besides, that tool appeared to be ahead of its time. We counted on a swift software migration to 64-bit systems to happen soon, but this process has appeared to be slowly dragging and it is still not over. We also found it a difficult task to tell programmers about 64-bit errors - they just wouldn't believe us. So our first step was a flop - just as it ought to. By 2011 we developed a general-purpose code analyzer PVS-Studio which happened to be more familiar to people, and we saw a sales boost as a result.
There was also some luck to it. Not in the sense that we didn't do anything and then it all just suddenly came to us. No, we did work hard - and one morning I checked my e-mail and saw a purchase-report from id Software by a user named John Carmack. I checked it several times and made sure it was not a fraud, and then I was very pleasantly amused. But it was when Carmack praised PVS-Studio from the stage at QuakeCon 2011 that I and all in our small team felt truly happy with what we were doing. And I want to clarify here why I am telling you about it. Not only to boast - though we felt proud indeed. It's just another thing which is very important: if you want to be mentioned and praised by some tough fellow of yours, you'll need to work quite a lot and that work may seem unnoticeable at first.
And what such a quick launch of CppCat is concerned, we managed it because we had worked on the product concept for a long time by then, and we knew all the drawbacks of PVS-Studio that we needed to fix.
KP: Wow, that's really a cool story about Carmack.
ER: By the way, we are currently selling both products, PVS-Studio and CppCat, so they live in parallel and help each other.
Picture 7 - Carmack is glad for Russian software products
KP: You're teasing Chromium, MTA, Doom 3, etc. at your site - doesn't it prove that bugs are infinite and it's impossible to find them all?
ER: Konstantin, you've touched upon my favorite subject - promotion of our products. Our target audience are tough and experienced programmers. Decision about purchasing products is made by a team leader (in large companies) or development director (in small teams). You may flood the whole Internet with bright banners "Our product is the best, buy it and forget all trouble!" — they won't fall for it.
Moreover, many programmers either use AdBlock or have worked out a habit not to notice banners and to show criticism toward advertising reviews. But a few years ago we found - or rather accidentally discovered - the most efficient way of promotion. We take an open source project - the more famous, the better - and check it. We pick a dozen of bugs from the list and discuss them in the article. Andrey is especially good at writing such articles - he has really become a master in that. What is the idea of these articles? We DO NOT mean to say that all those projects are written by novices and bunglers and make fun of them. We mean to say, "Look, even the tough Chromium developers sometimes make mistakes! What about you - do you think you are perfect? Get the tool and check your code."
People do like these articles, which inspire them to visit our site and download a trial version. The idea is simple. Programs are written by humans. And humans tend to make mistakes, you know that. Even the most qualified ones. The whole stuff is always in motion: projects are evolving, developers are writing new code and modifying old one. So mistakes are inevitable. The earlier they are diagnosed (either by our tools or by others), the cheaper it is to fix them.
Picture 8 - A program's screenshot (for the sake of formality)
By the way, we are very lucky with our target audience (i.e. programmers). I've become convinced of it during the years of work. Out of 100 reports, only a few are inadequate; most often, we get really reasonable bug-reports, stack-dumps, and even recommendations (which are often quite useful) on how to fix bugs in our tools. I just can't but compare our audience to that of other products (as told by our friends) and feel happy that we are so lucky with our users.
KP: By the way, what running CppCat on CppCat's code will result in?
ER: It's one of the most frequently asked questions. We regularly run our tools on themselves. They usually reveal bugs at the moment of writing the code, when analysis is invoked right after compilation. And here's where they all are caught. That's why you will never see us publishing an article with a title like, "We found 20 bugs in our analyzer". It's not because we don't make mistakes - we do, and quite a lot. But we get them fixed right away, so they don't even get into the bug tracker.
KP: That's great. Speaking of money, does your startup pay off? How many customers do you have, what's the turnover?
ER: From the viewpoint of business, we have always tried to be profitable as we started and maintained the company with our own money. To be more exact, we have never been at a loss because we just can't afford it. This is partly the reason why we are still a small startup, though we want to grow, of course. Speaking of the turnover, we saw 40 purchases of PVS-Studio during 2013. Not all of them were first-time purchases (many of our customers renew licenses at 80% of the original price for one year). Among those purchases were both ordinary, i.e. cheaper, licenses and more expensive ones (the Site License for a team of many developers); but there were also cheaper deals when we carried out an experiment with the pricing policy. So these figures make a good estimate of our business. Not great, of course, and anyone would crave for more. But this is how it is for now.
What CppCat is concerned, it's a bit too early to give any figures as the product was only launched in January 2014, and, as I already said, you don't expect millions of installs in our area.
KP: Frankly, did you really start it all on your own, without any investments?
ER: Yes. However, when we only started and Russia didn't see such an investment boom like now, we communicated with some investment funds. They all answered, "Welcome when you have an established business". When we got an established business, they answered, "Welcome when you reach SUCH-AND-SUCH income level". And when our income reached that level, we did not need them anymore. So we haven't contacted any investors since then. This is our experience of trying to establish relations with investors. I suspect there are many cases when it may be mutually beneficial, but not for us with our narrow target area.
KP: Everything looks bright and neat, but the world is not that way. There must be something you are not satisfied with. What is it?
ER: That's true, there is always something you don't like, along with positive aspects. We don't like failing to reach a larger audience of USA and Europe developers, or a larger number of article reads and trial-version downloads. Although we work and try hard, results are still not very promising. Sometimes I take a look at a diagram of Google Analytics for our fellow colleagues and can't help wondering, "How do they manage to attract so many thousands of visitors? What am I doing wrong?" I can't but envy, "I wish I had traffic like this!"
And please no comments like, "Sure you won't get over to the USA and Europe from Tula!"
KP: Why, you are right. It doesn't matter where you are situated. People get to your website, not your office. So it's OK.
ER: Yes, but we just can't understand where, for instance, USA programmers hang about. That is, people give us addresses of some websites in comments, we pick the first five and try to carry out some promotional activity there. But it seems not enough. So, we are currently not very good at internet-marketing. I mean you can't just create a fresh account at a forum and write there, "Hello guys, welcome here - analyzers for download".
KP: Well, I'm sure you'll make it one day.
ER: No doubts :-)
KP: Thank you very much!
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
0