{"id":3061,"date":"2014-03-28T15:00:07","date_gmt":"2014-03-28T19:00:07","guid":{"rendered":"http:\/\/me-en.kaspersky.com\/blog\/?p=3061"},"modified":"2021-08-09T17:44:51","modified_gmt":"2021-08-09T13:44:51","slug":"the-rule-of-six","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/the-rule-of-six\/3061\/","title":{"rendered":"The Rule of “Six”"},"content":{"rendered":"

One of the most important milestones Kaspersky Lab hit to become a renowned global player in the security industry was the release of the then revolutionary version of Kaspersky Anti-Virus 6.0<\/a>. Officially launched in 2006, the product was a raving success on the global antivirus market, establishing Kaspersky as a technology leader for years to come. It would be immodest to call our product the best antivirus solution in the world<\/a>, but a number of magazines and independent benchmarks<\/a> did it for us.<\/p>\n

\"kis6b\"<\/a><\/p>\n

The path to success was nothing short of patchy and loopy \u2013 and hopefully someday some writer from Hollywood will take it and run with it, but for now, we will try to share our success with photos, notes, and memories from the original team of developers. We hope this story will act as a guiding example to young developers making new apps and services today \u2013 provided they are as possessed by the idea of becoming the best as these original \u201cSix\u201d creators were.<\/p>\n

\"A<\/a>

A renowned photo made on the day of the technical release of the \u201cSix\u201d version<\/p><\/div>\n

Problem 2003<\/span><\/strong><\/p>\n

The success of the \u201cSix\u201d was rooted in the downright catastrophe of the previous version. In fact, this fifth version never saw the light of day as it was originally conceived.<\/p>\n

To understand the essence of the catastrophe, one must travel back to 2002: Windows XP had barely hit the shelves; CPUs were able to finally scratch 1 GHz of clock rate; and the relatively young antivirus industry was yet to encounter a totally new variety of threats. All antivirus companies eagerly extended the capabilities of their products: at the time a competitive solution had to include a firewall, a constantly running file system monitor, and dozens of other features.<\/p>\n

With a powerful scanner engine built back in the 1990s, the Kaspersky dev team admitted that packing the solution with even more new features would make it unbearably slow \u2013 even the then-existing V4.0 was readily condemned by users (there were all sorts of allegations saying \u2018Kaspersky is slow\u2019 back then that were an integral part of the PC folklore). That was the reason why the development process of the new V5.0 was approached with a great care, considering the core business essentials: a new CTO appointed, a new development framework employed, and a new antivirus architecture chosen.<\/p>\n

The company dispatched its entire pool of resources to support the project. Still, in a year\u2019s time, the conclusion that following all these new development rules would not necessarily guarantee the creation of a competitive product was decided upon. The resulting system, which parroted enterprise-class client-server apps (the choice of architecture made by the CTO), was not able to meet the requirements imposed on the antivirus products by the market. It was slow and heavy and the number of bugs was not decreasing as the team ran the tests. The number of bugs \u2013 in fact \u2013 was increasing.<\/p>\n

\u201cI started to ask people, our company veterans, what they think. They said it was all about the architecture. It was like the house of cards: on fixing one of them, you bring down the entire stock,\u201d Eugene Kaspersky admitted. So it did not make any sense to continue with the project as it was. It had to be entirely demolished and built from scratch.<\/p>\n

We can do it!<\/h2>\n

The Kaspersky Lab dev team forked into two groups: one struggling to fix the product regardless of unwisely chosen architecture, and another to publish the previous V4.0 into a suitable new product.<\/p>\n

At the same time, a group of four decided to make a completely new product not only to be compliant with the market requirements, but to be future-proof as well. The goal, which was set by the \u201cSix\u201d dev team, was easy to explain but hard to achieve. The new version had to prevent all viruses and threats from leaking into the system, it had to be fast, agile, and transparent, and\u2026 well, it had to be nice-looking.<\/p>\n

\u201cWe just wanted to make the best product ever\u201d, the Six developer team reminisces. A very small team beset with a monumental task, as it was perceived by the rest 200 staff members. Yet the small team on this challenging mission had their reasons to be optimistic: the company founders, Eugene Kaspersky and Alexey De-Monderik, were at that time seeking alternatives for a new architecture \u2013and they were to discover that the alternative existed and was invented by none other than the Kaspersky team.<\/p>\n

Help coming from Prague<\/h2>\n

\"Prague\"<\/a><\/b><\/p>\n

It must be said that two antivirus cores (so called \u2018engines\u2019) were operating in a bundle under the hood of V4.0. The checking of files was done by the old, very capable (and massively licensed by a bunch of international companies, from G-Data to F-Secure) V 3.0 engine developed back in 1996. The newer task of powering the filtration of the web traffic was handled by the brand new and powerful mechanism conceived in the course of a brainstorming session in Prague in 1998.<\/p>\n

The engine ended up being dubbed \u2018Prague,\u2019 despite the fact that it was developed in Moscow by Andrey Doukhvalov, who had not attended the brainstorming session in the capital of the Czech Republic. The key ideas, however, originated in Prague, and Andrey joined the company to tweak the ideas and implement the Prague concept.<\/p>\n

Prague was intended to become a purely anti-virus core, but the goals set for it were so ambitious that the newly developed engine\u2019s flexibility and ingenuity were enough to power even more complicated systems. The question, whether it is possible to implement the entire product<\/b> based on Prague, weighed heavily on Kaspersky as he spoke to the developers. He recalls:<\/p>\n

\u201cOnce I asked Victor Matyushenko how Prague was coping inside of the product, and he said it was \u2018Solid as a rock!\u2019. That was the breaking point. Then I just formulated the <\/i>question. I walked into the room where Graf [De-Monderik] and Petrovich [Doukhvalov] were working and asked them the <\/i>question: \u2018Why don\u2019t we base the product entirely on Prague?\u2019 Graf said something along the lines of \u2018impossible-prague-is-not-intended-for-this,\u2019 but Petrovich hesitated. The next morning he came up to our office with a little stack of paper, and he told me, \u2018You know, I coded some use cases on Prague. Graf looked up to him and said, \u2018We have to have a little chat.\u2019 Then \u2013 after chatting \u2013 they joined me again and confirmed it was worth trying.\u201d<\/p>\n

The trial started with a very concise team who wrote the first lines of code which were later to become the \u201cSix.\u201d<\/p>\n

The trial started with a very concise team who wrote the first lines of code which were later to become the \u201cSix.\u201d<\/div>\n

\u201cWe started to look around in order to find people who could get creative and contribute something, and we gathered an extended team,\u201d De-Monderik remembers. \u201cTake Pavel Mezhuev, a coder, he was a newbie \u2013 yet bright. \u00a0There was Mike Pavlyuschik, whom we had been long working together with. He was capable of generating out-of-the-box ideas and concepts. I thought he was one of the most talented and industrious creators on the playground.\u201d<\/p>\n

\"dec2003-ppp\"<\/a>After two months of open floor, experimental coding, we reached the decision that the project would become a commercial solution. Now all we needed was a project manager.<\/span><\/p>\n

\u201cRemember Nikolay Grebennikov from the office next door? He reads quite a lot, he is young and he is new to the company. Let\u2019s take him!\u201d Andrey Doukhvalov says, remembering a conversation he had with De-Monderik. Andrey Sobko, a driver software engineer, would join the party a bit later.<\/p>\n

What is \u2018Prague\u2019<\/h2>\n

This section is of more interest to software engineers. The rest of our audience can freely skip it.<\/p>\n

<\/p>

\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl><\/div>
\nEven in the early days of the 1990s, as the antivirus industry was just emerging, there were viruses undetectable by regular signatures. As an example, a polymorphic virus, which encrypts its code differently with each infection is not detectable within the signature approach. As software became more complex, in the world where Internet penetration skyrocketed and malware coders turned from having fun to offering their service to the market, malware turned into an increasingly more sophisticated and manifold threat. Even with an engine incorporating additional capabilities over the signature-based detect algorithm, as it was at Kaspersky, the developers were forced to constantly update the very antivirus, not just signature databases, should they encounter a malware utilizing new principles. It significantly slowed down the reaction-time to new viruses, and the success Kaspersky Lab got after becoming the industry-first to cure the infamous CIH (Chernobyl) virus proved that reducing the time of reaction was well-worth every effort.<\/span>\n

With that in mind, in 1998 Kaspersky suggested to colleagues that the time had come to go and elaborate on the new anti-virus engine. Where could they go?<\/p>\n

\u201cThe company was short of money,\u201d Kaspersky said, \u201cand we had to find the cheapest place near Moscow to leave the city and mull the problem over far from the noise and rush. The place had to be entirely disconnected. There wasn\u2019t any Wi-Fi around at that time. The cheapest place turned out to be a European capital, namely, Prague.\u201d<\/p>\n

By brainstorming the new antivirus engine version, the Kaspersky Lab team reached the conclusion that an object-oriented approach was the best solution for the engine layer, that is to say, each analyzed file or object had to be dissected based on its structure, and the objects inside had to be detected, analyzed, and checked. The object management, in its entirety, had to be executed at run-time.<\/p>\n

All existing object environments were discussed and rejected due to being inflexible, memory-devouring, or slow. An idea emerged in the course of discussion: to develop our own environment, which would include memory management capabilities and other service procedures, which would give the antivirus the ability to dissect and analyze a potential malware code in a fast and efficient manner.<\/p>\n

The overarching idea was born in Prague by De-Monderik and Andrey Krykov, and was supported by the first lines of code provided by Doukhvalov and Kryukov.<\/p>\n

Then, for over a year, it was mainly Doukhvalov who continued to elaborate on Prague \u2013 this was the reason Kaspersky Lab hired him, after all. Having an architect expertise, Dukvalov ensured Prague would be flexible, scalable, and easily deployable into the product without invoking any architectural limitations. Ultimately, the goal was to build a multiplatform solution.<\/p>\n

The object hierarchy was a bit challenging to debug, but a convenient inter-object message exchange system and a minimalist programming interface made Prague an easily integrated architecture to use on-demand where applicable.<\/p>\n

\u201cIt was intended for component approach,\u201d Doukhvalov proudly notes. \u201cThat means, component could be added to an existing program. The system was very open, with opportunities to add elements and change its behavior patterns.\u201d<\/p>\n

A component-based architecture, compact and not resource-intensive, per common agreement, was the basis to introduce a series of radically new technologies to KAV 6.0. They were easily implemented. Moreover, when Prague was tweaked to serve as the basis for the entire product, and not only an antivirus engine, Pavel Mezhuev significantly contributed to fine-tuning the architecture:<\/p>\n

\u201cWe implemented one more architectural solution, deploying a model of separating business logic and an interface. Also, Doukhvalov and Mezhuev created a task manager which was able to control any single process within the product, and the process reciprocity was very simple\u201d, states Nikolay Grebennikov, who was the project manager for KAV 6.0.<\/p>\n

\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl>
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\"\"\n\t\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t<\/dt>\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/dd>\n\t\t\t\t\t\t\t<\/dl><\/div>\n

The principle of \u201cSix\u201d<\/h2>\n

Considering the trial and initial development stage were both carried out by a small group, it became clear that the monstrous project management approaches would not work for the team. As a result, an approach similar to SCRUM, was implemented: the developers would be seated in an open space, continuously interacting \u2013 thus they readily covered all aspects of the development process. That was the way the \u201cSix\u201d development team worked.<\/p>\n

Short profile: SCRUM<\/h3>\n

SCRUM is a project management approach for agile software development environment. It is based on the principle that the customer (user) does not necessarily know exactly what they need and may change the requirement in the course of the process. That means the development process is characterized by presence of consequent and numerous cycles: building \u2013 demonstrating \u2013 analyzing feedback \u2013 updating the version.<\/p>\n

But the SCRUM distribution of roles was significantly reviewed. Kaspersky has defined six roles:<\/p>\n

Architect<\/b><\/p>\n

This is a person \u2013 actively involved in the coding process \u2013 who knows what to build and how to build it.<\/p>\n

Technical designer<\/b><\/p>\n

There is no straightforward definition for this role, but the person is responsible for ensuring that certain solutions are brought to life. Perhaps more importantly, the technical designer must know how NOT to do things.<\/p>\n

Inventor<\/b><\/p>\n

The inventor applies unconventional solutions to solve problems. In the case of \u201cSix\u201d, the problems were countless. The solution had to ultimately provide the highest level of protection yet consume the least amount of computing resources.<\/p>\n

Project Manager\u00a0 <\/b><\/p>\n

The role of project manager in SCRUM does not strictly presuppose regulation. He controls the resource pool and deadlines, but he is not an immediate leader. He does not command the coders on what to do, but motivates them to take the lead themselves.<\/p>\n

\u201cThe team was small we did not even have a chief person at first,\u201d Doukhvalov says. \u201cThe manager was planning, reporting, but the decisions we were taking on the project itself were collective.\u201d<\/p>\n

Marketing manager<\/b><\/p>\n

The product is created for clients, not for the dev team itself. It is vital to have an understanding of the expectations the prospect users judge the product against, and how they are going to use it. While the operational principles are defined by those who understand the nature of the anti-virus functionality, a thousand little things such as settings, messaging, or UI, have to take user requirements into consideration.<\/p>\n

Psychologist<\/b><\/p>\n

Working under pressure, lack of sleep, in-group conflicts, instability\u2026 Someone has to ensure the environment in the room is friendly and productive. This role was assigned to Kaspersky himself, so he predictably combined it with the role of a sponsor, who provides funds and resources to the team and protects it from outside influence.<\/p>\n

Frankly, there is one more role which is of vital importance for SCRUM projects \u2013 it is a scribe<\/b>, who takes notes on the process. But this position was not occupied by anyone, and it created problems.<\/p>\n

\u201cWe did not know why we did this or made that decision only half a year ago,\u201d Kaspersky affirms.<\/p>\n

According to the principle, the number of roles does not necessarily correspond to the number of team members. One role may be distributed amongst several people, while a single member can perform several roles.<\/p>\n

\u201cWhile preserving a formal organization, we acted as a single team, so there were blurred lines between roles: in particular, when brainstorming, people took over different roles\u201d, Nikolay Grebennikov confesses. \u201cSay, one person was coding, yet expressing his view of the design \u2013 and it counted. I myself was a Project manager but also participated in discussions \u2013 so those blurred lines really contributed to our success, as we cared about any single element of our project.\u201d<\/p>\n

According to De-Monderik, the coders were highly interchangeable: \u201cEach member of the team was God of is his domain, yet 50% of his skills were overlapping with someone else\u2019s. Mike was able to code drivers if Sobko was not present, UI specialists could handle some engine-related tasks and vice versa. I could do designs instead of Max Yudanov, and Kolya Grebennikov at times could design skins as well\u201d.<\/p>\n

It is crucial to understand that each role is leading on a specific stage of the project execution. During the start phase, the architect is the center figure. The inventor comes into action during the middle stage of the development process when the features are created and developed. And during the last stage, the key figure is the manager as the project now has a lot of resources which require tight management in order for the team to be able to make the deadline.<\/p>\n

In pursuit of the ideal<\/h2>\n

Given the \u2018SCRUM\u2019-ish approach and the overall ambitiousness of the project, \u201cSix\u201d did not have any static requirement list. According to the basic requirements, the product had to feature the following capabilities:<\/span><\/p>\n