Agile in our opinion, or something about Russian innovations in software

    When they say that Made in Russia innovations are just controversial projects like the E-Mobile of the Cherepanovs steam engine, clearly undeniable like space rockets and other semi- and completely non-military products, or bare ideas for export, do not believe it. We have something to brag about, and I am proud of it.

    Over the past twenty-twelve years, my company has grown from a small, small-town fly agaric to the tops of IDC ratings and the top-right corner of Gartner's “magic square”. A beautiful office on the main street of the country, Elephant Dali at the reception, almost 3 thousand people in the state, 30+ offices around the world ... and other praises. But this is not about that.

    Why did it happen? Many reasons. For example, my invariable principle: to try, try and not be afraid of mistakes. And also - an affiliate program, working with retailers, online providers, capitals and provinces - there were a lot of things there, but this is not on this topic.

    All of the above is secondary (forgive me those who carry this service). Primarily - our technologies and products (in the sense of just software, not “software + everything else”). Since if there is software - everything else can be configured. If there is no main thing - goods - then everything else does not make sense to build. Otherwise, the business (sales) will be either one-time or corrupt, which categorically and fatally disgusts me.

    So, software. What can be proud of here? There is something! I’ll tell you, dear Habravites, about the Six.

    Most recently, we celebrated the eightth anniversary of the launch of the revolutionary (for its time) sixth version of KAV (Kaspersky Anti-Virus, I mean), a product that broke (literally) the home antivirus market in 2006-2009. Which brought together super-inventive technologies: proactive virus blocking, ease of use and a minimum of resource consumption (yes, it’s from the Six that we no longer slow down). Breakthrough methods of working with world retailers, online marketers and marketers I leave aside, this is a topic for another conversation. Figs with him, next time.

    Briefly on technology:
    - built-in object environment for parsing arbitrarily complex objects and expanding the antivirus functionality with new components “on the fly”;
    - detection and blocking of malware without signatures, by their behavior in the system;
    - replenishment of anti-virus databases when an unknown virus is detected (this is where all the anti-virus clouds started!);
    - rootkit detection and treatment system;
    - Optimized and accelerated antivirus scanning;
    - for starter - a quick and compact update of the application, in which only modified fragments of the file are downloaded.

    Thanks to all this, the Six turned out to be fundamentally better than previous versions. Essentially better than previous versions of oursproducts, and for years ahead of all the home products of our main competitors. And not the main competitors either. This product caught viruses like Pokryshkin messerschmitts, while being very compact, imperceptible and fast in all the good senses of these words. True, it was developed for a very long time, almost three years, and with great adventures. We are thinking of taking their description to Hollywood Mosfilm, but here I simply admit that in order to create this project we had to invent our own kind of agile methodology based on SCRUM, fire the technical director, hire a new one and fire him, and also put the fifth version of the product under the knife ... The way to victory was not easy and thorny.

    Under the knife

    Why did two directors and one product go to the chopping block? That was 12 years ago, the year 2002. Who remembers those times? Windows XP has just arrived (by the way, remember the old woman, “all the best, and thank you for the fish”), 1 GHz is pretty cool, it’s another 5 (five!) Years for an iPhone, but on the anti-virus front it’s more fun with the popularity of the Internet with every in the afternoon. All new types of virus appear (Melissa, RedCode, all kinds of Slamers), and anti-virus companies are forced to increase the functionality of the product. Inside the antivirus should be a network firewall (or a firewall, if you prefer words from German), a constantly working file monitor, and dozens of other functions. Our "four" could not cope with such a load ("Kaspersky slows down" - this is exactly from there, from that era), and we, having said goodbye to the technical director of the "four", hired a new one. So that he makes us a modern antivirus that catches everything and everyone. And it does not slow down, infection! For the new right director to recruit the right people, choose the right organizational structure, the right project management method, the right quality control - well, you know. He had to do everything. We (the company) for this have provided all possible resources - human and financial. The main thing is to do !!! The rest is earned.

    And ... fuck there! After one and a half (or two) years, almost all the developments had to be put into the basket. The new technical director has created ... to put it mildly, a system that is not quite suitable for the requirements of a commercial software product. Management techniques were copied from software outsourcing, and the technical architecture of the product was built according to the canons of corporate client-server applications. All this, sorry, the crap did not meet the requirements for a commercial home antivirus. Not only was the prototype of the “five” cumbersome and slow, it did not decrease the number of errors as it debugged! We started talking with our old programmers, asking their opinions. They say the wrong architecture. It turns out a house of cards. Here corrected - there it fell apart. Therefore, to bring the project in its current state did not make sense.

    About the benefits of Czech beer and the object approach

    Although we did not know about this, we already had a solution to the problem: an architecture suitable for creating an antivirus was already developed. She worked in the “corner” of the fourth version, filtering web traffic. We conceived it in Prague already in 1998 (yeah, we were looking for a cheaper place in the Moscow Region for a brainstorming session, but the Moscow Region turned out to be expensive, unlike Prague), but so far we hired a person who started programming it - Andrei Duhvalov - while he was doing something wrote, the 21st century has come.

    “Prague” (the so-called architecture) was written mainly for the analysis of complex malicious objects. Detect viryo “by carcass” (even polymorphic) - this was already done by the 1992 engine. But to get the “carcass” from any object on the computer (for example, from a Word document inside the archive inside the mail database) - it was a very difficult task. "Prague" was able to do this. But in order to “teach” it to this, it was necessary to lay such a powerful potential in functionality that it would be enough for something more than an anti-virus engine. Those who used Prague in KAV 4.0 praised it very much, and one day I had the Main Question.

    As we all know well from the educational course of the preparatory group of any kindergarten, half of the solution to any problem lies in the correct formulation of the Main Question. If you correctly asked the Main Question, it means that half of the budget has already been mastered. The tasks have already been completed.

    So, the main question! I asked Petrovich and Graf (Andrei Dukhvalov and Alexei De-Monderic, the first LK programmer): is it possible to make the whole product in Prague? The count answered something like: “Impossible,“ Prague ”was created for other purposes,” but Petrovich said nothing, but the next morning he came with several sheets of paper. And he said: “Listen, but I wrote some use cases in Prague.”

    The count looked and said: “Come on, let's talk.” Then they came to me and said that we can try to drive all our cattle through this particular quagmire.

    A little more about Prague

    I’m not sure that each of us will enjoy digging in the “stomping ford”. And then to remove the jeans from the sensations obtained is generally the work of very stubborn hands (google “mad mud road / trip / hike). Therefore, here is a small essay, which, incidentally, does not belong to my "pen", but exactly coincides with my worldview.

    Any specific details about Prague
    Due to the fact that Windows and the Internet greatly diversified the world of threats, and in addition to the usual file virus, a lot of new things appeared on computers, we needed an object approach for the anti-virus kernel. That is, the engine must understand that any object on the computer is a certain hierarchy, and be able to go deep into this tree as deep as it takes to find and analyze potentially dangerous code there. It would seem that OOP was popular in the nineties, the tools should be full! In fact, nothing ready came up for us. First, the construction of objects and all manipulations with them should occur in runtime. Not every object environment preserves “objectivity” at the stages after compilation. Secondly, the antivirus should build and destroy objects very quickly and in great numbers, while saving memory. All encouraging options rained down on this demand. As a result, the idea arose to create “from scratch” your own object-oriented environment. Dukhvalov worked with this idea for over a year and programmed it as a flexible architecture that was easily integrated into the product. Objects could perform almost any function, therefore, in addition to parsing the hierarchy of objects in search of viry, on Prague, it was possible to expand the functionality of the engine with plug-ins. In fact, it was based on a very compact kernel that controlled memory, property inheritance, and messaging between objects. A very simple API allowed the use of "Prague" where useful. In addition, she was ready for multi-threading and multi-platform, which the old engine could not do. The main drawback of the architecture was one - in multi-threaded applications, objects were difficult to debug, and quite a lot of time during development took exactly that. I even had to write my own exception tracing toolkit. But it was thanks to Prague that the Six added so many new features that were easy to integrate.

    Our SCRUM

    Began the development of the "Six" literally a handful of loonies. In a good, true my understanding of the term "crazy!" Architecture - "Prague". The task is ambitious. We want to make the best product, and that’s it! The main idea is to catch all the vire, not to slow down, to be pleasant to the touch. And visually, too, to be "ah!". How to approach this large-scale development?

    For a handful of loonies, CMM and other fashionable then not fashionable design techniques are not very suitable. Agile methods ten years ago were not mainstream, and the whole topic had to be unearthed, studied in detail by ourselves. As a result, after reading books and arguing, we took a heavily shabby SCRUM as a development methodology.

    From scrum we took the main thing in organizing the process: short iterations between builds, developers sit together and constantly communicate, everyone cares about everything. True, the role system was not at all scrum, but it worked fine for us:

    • Architect : a person who knows how and what to build. In the Six, he also took an active part in programming itself;
    • Technical designer : for this role, no one came up with a more accurate name, but this person is responsible for the implementation of specific solutions and, more significantly, works as the “main debater”, who knows how to do certain things;
    • Inventor : the embodiment of innovative solutions for specific particular problems. There were a lot of them in The Six. In the end, it was supposed to provide the maximum level of protection with minimal resource consumption. If something had to be done, but no one understood exactly how - they said to him: “Go home, think up in the morning, it’s necessary”;
    • Project manager : as in classical scrum, our manager is not the boss. He controls resources and timelines, but does not directly manage, but only encourages developers to take the initiative. “The team was small, at first even the boss as such was not. There was a manager who summarized plans, made reports, but basically we made collegial decisions on all issues, ”Dukhvalov recalls;
    • Marketing Manager : among psychos there should be a person who reminds them that the product is not made for themselves, but for customers. In the broadest sense of the word. Customer = who pays the money, who is the partner, who is tech support, who sells personally - and everyone else too! You can know a hundred times how to make anti-virus protection, but how to show it to the user so that it is convenient, clear and not scary - the marketer decides. Feedback was collected on the forum and directly in the LC. We regularly went around the office of the company, took on sales managers, technical support - and on all of them “ran” the beta versions. According to the results of the survey, the employees made the necessary changes, for example, at the request of technical support, they switched to English with one button;
    • Psychologist : as our driver Andrei Sobko said, the most difficult part in the development was to agree with colleagues. They are all terribly stubborn. Of course, these are all creative conflicts, and they were very productive, but still - nerves, a lot of work, few days off and sleep. Someone needs to make sure that the atmosphere remains friendly;
    • Documentator : I want to take the word "Documentator" directly into a triple frame. We simply couldn’t take the person to the role of the Documentator, there was no money dumb! And he is really needed - someone who records everything that happens. Without him, after half a year, we no longer knew why this or that was done that way.

    In the whole story with roles, it is important to remember that the number of roles and people is not connected in any way. One role can be distributed across several people, while each member of the team can play several roles.

    Here the Earl said well: “Everyone had an area where he was cool, but at the same time 50 percent had every other. Mike could write drivers, if suddenly Sobko did not come, interface specialists could pick up work on the kernel, and vice versa. “Instead of Max Yudanov, I could draw something, and Kolya Grebennikov sometimes drew skins.”

    Nikolai Grebennikov and tablets list of features of the first beta version

    And of course, each role is important at its own stage of the project. At the start, the first violin is played by the architect. The inventor is most important in the middle of development when specific functions are invented and programmed. And in the end, all the power must be given to the manager so that he brought the product not to perfection, but to release on a specific date. Perfection can be brought to infinity.

    About the timing

    The problem of deadlines and todo lists was with us during the development of the Six, and it was very acute. On the one hand, there was no fixed TK, and product requirements changed many times during development. We prototyped, discussed, wrote lists of requirements and functions, wrote the most important thing on yellow pieces of paper, glued them to the monitor, forgot, remembered and so on. Five blocks have passed from alpha to technical release! On the other hand, as a result, the product includes many functions that we did not think about at first, which made it revolutionary. Here, of course, our forum played a big role.

    Although from September 2003 to March 2006, while the Six was being created, a lot of new tasks appeared in it, and the team grew to almost thirty people, there was one thing that didn’t have enough of a dedicated team. This is a beta test. The product is new from and to, written from scratch. The product is complex, so a huge amount of testing is required. For the first time, the approach of regular assemblies was applied, that is, first weekly, then daily. As a result, we argued, argued, and decided on forum testing. Thanks to several thousand members of the forum, KAV6 was very well tested! All developers were very active in the forum with testers. “Five hundred people were very active. They were waiting for a new assembly, they installed it every night, ”recalls Kolya Grebennikov, a former KAV 6.0 project manager. He sat on the forum for many hours every evening and sometimes even fell asleep right above the keyboard. However, we all sat in the evenings, because the enthusiasm was hoo. Burning eyes, a boiling pot of ideas - the best time in life!

    Yes, returning to the forum - he helped us and prevented us. It helped to release an excellent product, prevented us from meeting the deadlines :) According to the results of forum testing, we had a huge list of improvements, but at some point I had to close it for addition. Grebennikov vowed to release me before the end of the first quarter of 2006. And they managed to do it at 18:30 on March 31!


    What did they fight for and what did they get? Got a real bomb. The list of patents and unique technologies is impressive. But the wrapper for this all turned out to be excellent too. A very compact installer by the standards of 2006. Quick work. Beautiful interface with skins - users even drew an anti-virus window to their taste. With the Six, we just rushed to the western markets, Symantec simply went crazy when American magazines began to give us gold stars. And everywhere, in all magazines we received the highest marks. And not only in magazines, the top sales of Amazon antiviruses and other stores immediately turned green. All this is due to the right choice of product architecture. And it was possible to translate it into a product thanks to the development process, which was well adapted to a small team of crazy enthusiasts.


    Instead of a conclusion

    In the SCRUM book that we read then, I read one interesting rule that I remember and which I apply not only in development. If something interferes with development, it should be eliminated first. All. Point! It doesn’t matter what it is. As a result, if a developer needs something, he should be given it immediately. On the first day that the project started, I ask: what do you need first of all? “Coffee maker,” answered Petrovich. The next day they had an expensive, chic coffee machine.

    The mascot of the project and part-time is the first coffee machine in LK. Already does not work :(

    The project turned out!

    And the last one. Recently, we had to part with one of the key, most important people from the Six. Nikolai Grebennikov went his own way, the company continues to go its own way. This is a technical essay I dedicate to Nikolai Grebennikov, who was with me for 10 years, with whom we rolled mountains, and which I will always remember until I die.

    Eugene Kaspersky

    Also popular now: