"There will always have to develop": an interview with Evgeny Kuvshinov (ManyChat) about the development of a

 3r3308. 3r3-31. "There will always have to develop": an interview with Evgeny Kuvshinov (ManyChat) about the development of a  3r3308.
 3r3308. We all roughly imagine how the development looks in a large company and how the development can differ from a small one. And what happens if the size of the company is changing rapidly, and the number of employees in a couple of years increases tenfold? When a startup is growing rapidly, and it is necessary to adapt to new circumstances on the fly, how does this affect everything (from processes to technologies)?
 3r3308.
 3r3308. At our conference, HolyJS will take part company 3r33232. ManyChat [/b] which is exactly what happens. Therefore, we questioned the technical development of the frontend 3r33282. Evgenia Kuvshinova 3r3r-2383. and specifically about ManyChat, and in general about what it is to do (frontend) -development in a startup. special bot .
 3r3308.
 3r3308.  3r3308.
 3r3308. - Surely you constantly hear the words "But chatbots failed a couple of years ago." Does your experience show that they are quite appropriate in a specific context?
 3r3308.
 3r3308. - Yes. Perhaps most of all the expediency is proved not even by our case, but by the WeChat platform. This is an instant messenger that almost everyone uses in China, there are a lot of businesses in it, and such things as ordering a pizza or a taxi are actively taking place in China via WeChat. And this shows that certain interactive scenarios of communication between a person and a business really work well, it is convenient for both parties.
 3r3308.
 3r3308. And those yuzkeys that were HYIPs a couple of years ago - like the fact that you can communicate with the bot as a person and he will offer the best flight option on the plane - well, it really does not work very well.
 3r3308.
 3r3308. And we are implementing something close to WeChat, but in other markets: first of all, in the USA, albeit throughout the world too. We have a fairly large number of customers from Europe, and in countries around China, too, many now use Facebook Messenger.
 3r3308.
 3r3308. - Turning to the topic of growth: how long did the company appear, and how did it grow from that moment to our time?
 3r3308.
 3r3308. - The company appeared in 2015. It began with the fact that its co-founder, Michael Jan, needed to be sent to the Telegram (there were no channels then). He realized that it was quite difficult, and a special tool would be useful. As a result, Mikael and Anton Gorin first made a platform for creating bots in Telegram. The platform began to grow quite quickly, they hit the startup accelerator in the Valley.
 3r3308.
 3r3308. In the meantime, they were in the accelerator, Facebook opened the API for Messenger. And that was the moment when they decided to make a sharp pivot, to make a new product just for Facebook Messenger. The monthly audience of Messenger is 1.4 billion people, and on Facebook a lot of companies have their representative offices in the form of official pages. And for these pages you can create bots.
 3r3308.
 3r3308. Initially, there were three employees: Mikael, Anton and another developer who made the very first version of the frontend. In the autumn of the same year, the first investments were received and it became clear that one could begin to expand the team. Then I and three other developers came to the company, so at the end of 2016 we were seven. And now, two years later, there are already more than fifty of us, and the growth continues.
 3r3308.
 3r3308. If you look at the numbers of the platform itself, then we already have more than 40?000 connected bots. And we are growing well in terms of financial performance: we are currently a profitable company, while continuing to look for investments in order to grow even more actively. Next year, by the number of people, we plan to at least double.
 3r3308.
 3r3308. “Startups are a very experimental area, where a lot is done by trial and error (like the aforementioned pivot, when we started with one concept, and then changed it on the fly). How does this affect development? Does this mean that you always have to be ready for the situation “the feature you implemented will be thrown out”?
 3r3308.
 3r3308. - Indeed, there is such that you can make some kind of feature, but in the end it will not be in demand by users, it will have a low adoption. Or she may not get to production at all, because we ourselves, having looked at the resulting, will understand that we do not like it.
 3r3308.
 3r3308. In order to minimize the number of such situations, the very first thing we think about (not even in development, but at the beginning of product development, features) is motivation. Why do we do it, for whom, how much will it affect already existing users, how much do we like it ourselves (will we be happy and proud that such a thing has appeared in our product). Having decided on motivation, perhaps, having conducted surveys in our user community or some other interviews with our users, we will start the development. Next, we are preparing a feature for the sprint, such a process is called PBR (Product Backlog Refinement): first, it gets into the backlog, then rises there by rating, and at some point it, already well described, can get into the sprint.
 3r3308.
 3r3308. Directly in the sprint, the first thing we do is, if we don’t understand how it will look, we make some kind of mockups and prototypes. But, however strange it may sound, sometimes it is already done with the development. Because sometimes it is very difficult to understand how the user will feel with the interface, simply by making some layouts and drawing illustrations.
 3r3308.
 3r3308. Quite often on the front end we make prototypes or interactive features that, in principle, are already working, they can be called and felt. And then, in close cooperation with designers, we bring these prototypes to the version that goes into production. But, nevertheless, when creating these prototypes here is also a frequent occurrence, when you make it, you look, and you understand “no, it will not go, it is inconvenient”. We try to use our own product, make bots, so that even before our users find out where some problems may arise. Well, in general, we focus on user experience, trying to build the most simple to use platform.
 3r3308.
 3r3308. - With the rapid growth of the company, you are surely faced with the fact that the processes that worked for several people stop working when you switch to dozens of people. How did your development change from an organizational point of view?
 3r3308.
 3r3308. - It was complicated. At the beginning of the year we had a rather difficult situation, when we had already done several features for several months, they were always able to “finish a little more and roll out into production”, but this “still a little” did not come.
 3r3308.
 3r3308. When we started, we were seven people. We had a scrum, there were sprints, everything was built and went on quite well. When we grew to 20-30 people, we, like many companies, had functional teams: backend, frontend. With their processes, with their sprints inside, with their queues of tasks. And we didn’t do the tasks that are specifically called “such a feature that will benefit such and such a user”. The tasks of each team were called in the spirit of "frontend: to overturn this way a piece of the interface, add some button."
 3r3308.
 3r3308. And it was bad for many reasons. First, when we have many different queues and pieces of the same business task are in them with different priorities, it becomes almost impossible to understand when the task will be completely ready. And it becomes more difficult for a particular developer to understand what he is doing. Because he does some piece described for him, and how the users will be happy with the result later, he doesn’t know, because he may not even know in many ways why all this is needed.
 3r3308.
 3r3308. At some point, we realized that it was impossible to go on like this. Yes, you can gradually tyunit, iterate, continue to carry out sprints and daily stand-ups (which have already started to take more than half an hour, because the whole team was present, but they did not give anything). But these are cosmetic measures that do not solve the main problem.
 3r3308.
 3r3308. And at that moment one of the guys in the company brought to us the information that there is such a thing, which is called LeSS or Large-Scale Scrum: the scrum is for already large and growing teams. After sitting a few nights in the negotiations, discussing everything that is happening at us, the CEO and CTO (Mika and Anton) made a very difficult business decision: we will throw the whole development process (as we design features, implement and roll out) into the trash. Let's finish the sprint that is going now, and then build it all over again.
 3r3308.
 3r3308. The decision was difficult, and realizing that we are doing this, we still thought long enough: “Damn, will it work out or not?” But we decided to try it anyway by turning to the book on LeSS and certified trainers. We started in a new way, made cross-functional teams - there were three at the start. We launched short weekly sprints according to the rules of LeSS (rules in the sense of what set of meetings should be on these sprints). I will not tell all the details, but for the first weekly sprint of eight tasks that seemed to hang on us, which we could not roll out for several months, we rolled out into production, if not all, then most. And we just did not understand what was happening. How so? Why couldn't we do this before? And why did it happen? It was very cool and we began to move on, take new puzzles, solve them in cross-functional teams much faster.
 3r3308.
 3r3308. Of course, there were some difficulties and misunderstandings too. But on the whole, probably, most of the team is very pleased with the emerging process, because we have significantly reduced time to market for features, you can do everything very quickly, roll out into production. And besides this, we are trying to convey feedback from our users, so that developers can see how much people like what they do.
 3r3308.
 3r3308. Another interesting point was how we rolled out the front end after we switched to LeSS. We realized that now we are divided into separate cross-functional teams, and the first time (at least before the front-end community works), we will communicate much less. And we learned to roll out the frontend at any time “at the click of the fingers” when we need it We had one single meeting before the start of the new sprint, where we said that we have our main branch and it can be rolled out at any time . Before that, I had thoughts that we must build an integration UI test system that will check every build, that there should be a huge percentage of coverage, and only if it is “green” can we roll. But it was some kind of unrealizable dream, because the product is growing very fast, and in this case, no matter how hard you try, you still do not have time to keep a huge percentage of coverage. As a result, by agreeing with all the developers and giving them this responsibility, we managed to make sure that now the code from our main branch really always works and we can always just pick up and roll out any assembly that we need.
 3r3308.
 3r3308. - Wow, thanks for the detailed answer. I would like to suggest that, in addition to the described transition, there was also a transition from “full stack” to a narrow specialization: when only a few people do everything in the project, they have to do various things willy-nilly, and when there are more than fifty, each tasks. This is true?
 3r3308.
 3r3308. - When we were few, we really had to solve many problems from different areas. For example, I spent some time a little and did system administration, and set up a CI system. And now, with the transition to LeSS, this is much less.
 3r3308.
 3r3308. But this does not mean that everyone is now locked in narrow roles. When you come to the company, you have the core competence (even if it is a backender, even a designer), and no one will stop you from pumping this particular vertical into space, but at the same time LeSS gives you the opportunity (exactly the opportunity) to develop in adjacent directions .
 3r3308.
 3r3308. We are divided into small standard scrum teams, in which there are six (plus or minus three) people who are gathered together and sit side by side at adjacent tables. So, the fender can always communicate with the back-tender, and with the designer. Besides the fact that in this way a cool communication is built, you can also learn from these guys. And we welcome if a person who is engaged in the front, for example, wants to take some small backend task for this sprint and pump this area. Because, the more knowledge you have from different areas, the more you focus on the entire product, and then you are better able to solve your problems. When you begin to understand why designers do this, why productologists do it, sometimes you can start building the interface yourself, which you will then simply show them, and they will say “yes, great”. And, accordingly, you can do your work faster.
 3r3308.
 3r3308. - Startups are "at the forefront of progress." Does this mean that when choosing technologies you can easily drag something completely new into production? And are there any precautions so that it does not turn into a pursuit of “shiny new things” that could harm the company?
 3r3308.
 3r3308. - The short answer: yes, supernovae, cool and interesting can be, we welcome it in every way. But, of course, there are certain criteria for the introduction of new technologies.
 3r3308.
 3r3308. If you find some technology that you are interested in, then you need to bring it to the community. Although we do not have a front-end team in the company anymore, there is a front-end community in which we periodically gather and just discuss such issues. There you can tell everyone why it’s great and why it will be easier for us to live with it in the future. Some companies probably have some specific selection system, a complicated table with comparisons that needs to be filled out. We have nothing like that, all decisions are made at the level of some very subjective sensations, but at the same time we have really good and interesting technologies.very quickly.
 3r3308.
 3r3308. Sometimes there are those things that have not yet reached the release. We started using the library to create panels in React, when it was still quite raw, and, as I recall, we even completed a little of it there. We started using Babel 7 from some beta, because it allowed us to build a project a little bit faster than the previous one.
 3r3308.
 3r3308. And, probably, no one in the team has ever complained that he wanted some new cool thing, and they said to him: “No, we have such a policy, we will not do that”. And at the same time, I cannot recall a single problem that such an approach would have, which would welcome new and interesting technologies. It is very strange for me, because, in my previous experience, I made many wrong decisions at this very level. But in ManyChat, maybe, just with the help of the community, maybe even for some reason, we don’t have such files, when we chose something, and then we had to take and rewrite half of the code base to another technology, because this one didn't go.
 3r3308.
 3r3308. - More about the "edge of progress": I would like to assume that a startup allows you to quietly breathe, "you will not have to deal with the Legacy code." This is true?
 3r3308.
 3r3308. - Well, the word "legacy" everyone understands in his own way. If we mean by it, for example, a code older than three years, then in a company under three years old, of course, it does not exist. But it is possible to toughen this concept, then we will have a certain percentage of legacy code. From the point of view that even if it was written not three years ago, but only a few months ago, but then we did not know how to do something right, but now we learned, we can do a hundred lines instead of a thousand, and they will do the same is even more reliable. Such code, of course, is, it is inevitable. But there is nothing for which we would have to look for some "bearded developers", because only they know this programming language, and we cannot refuse it.
 3r3308.
 3r3308. - How much does the development in a startup contribute to “cycling”? While the giant companies are doing everything inside, you don’t care? Or is a startup just a place where everything is done in its own way?
 3r3308.
 3r3308. “For us, business value comes first.” We are already profitable, but if we slow down and start losing to someone, it will be very painful. Therefore, if third-party development is consistent with business requirements, solves business problems, and it does not have any major problems, then we boldly take it and use it. And if, after use, there is still some dissatisfaction, we set ourselves a task in technical debt that we want to do it ourselves better and better. But the most important thing is to initially close the task and give our clients the required features.
 3r3308.
 3r3308. - And how active growth affects the technologies used in the development? Does it often turn out that something “outgrow”?
 3r3308.
 3r3308. - Well, rapid growth is more about the backend. Our employees who are engaged in the backend, each month are faced with almost doubling load, they have to scale everything, add iron somewhere, accelerate something. And on our front end everything is much simpler: there are more new users, but each of them comes with his own hardware and launches our application in his browser.
 3r3308.
 3r3308. But there are changes. The first version of ManyChat was immediately on React, but we used the Baobab library to store the state. This is such an implementation of an immutable tree, and all this was connected to React through custom binding with actions. From the layers of abstraction there was actually a view with React, custom action games and a store with Baobab. It was not very convenient, a lot of things were missing, and in principle it was also quite difficult to dive into it.
 3r3308.
 3r3308. Therefore, in 201? we decided to take the technologies known to us and widespread in the frontend. We left React, added Redux with a small set of middleware for it - we took Thunk and wrote some of our own to work with the backend through the Fetch API. Reducers and selectors have been added to the layers of abstraction, and we have been living with this core for two years now. In principle, we are completely satisfied with everything, but the application is growing in functionality, but it remains good, responsive.
 3r3308.
 3r3308. “Since startups solve problems that they haven’t solved before, then technological problems in them may turn out to be different from those that everyone faces every day. Did you have something different from the “ordinary” frontend?
 3r3308.
 3r3308. - We have a tool for visual programming of interaction schemes between the subscriber and the bot, we call these schemes Flow, and the tool itself - Flow Builder. Here you can see what it looks like:
 3r3308.
 3r3308.
3r3304. 3r3304. 3r3304.
 3r3308.
 3r3308. It turned out that creating a responsive and smooth map interface with zoom, panning and a large number of objects cannot do without 2D graphics. As a result, our Flow Builder technically works on PixiJS - the universal renderer for WebGL /Canvas.
 3r3308.
 3r3308. In Russia, this technology is known mainly to developers from gamedev. But since we are not a game dev, we have our own specifics. In PixiJS games, every time after rendering, requestAnimationFrame pulls and constantly draws. If we do the same, then the user will leave the laptop with the tab open for half an hour, and when he returns, he will find that the laptop is dead. Moreover, the user’s laptop can be completely non-gaming (I then had a 12-inch MacBook, which cannot boast of performance, I tested it on it). In general, I had to look for different solutions so that everything on it was smooth and fast without discharging a laptop.
 3r3308.
 3r3308. As a result, for all elements of geometry and everything we use, we made our own proxy wrappers that register some changes, plus we made our own wrapper handlers for various browser events, and made it so that we only draw when it is necessary. So it turned out to make actually quite fast and convenient tool for 2D drawing.
 3r3308.
 3r3308. - And how much such tasks complicate life in comparison with the “typical” ones? For example, did you have to deal with the fact that Google does not give answers to emerging questions in this situation?
 3r3308.
 3r3308. - Well, I would like, of course, to say that everything was terribly difficult, and nobody did it to us Yes, most services remain within the framework of native HTML, and when you have to go to Canvas and WebGL to draw a significant part of the interface, difficulties appear . But choosing Pixi, we made a pretty good choice.
 3r3308.
 3r3308. We then studied a large number of technologies: we checked a lot of libraries that simply draw on Canvas, we took some other renderers for WebGL. But for us, Pixi turned out to be the fastest and most convenient, and most importantly, there is a fairly large community around it. The guys are actively willing to answer questions, help fix bugs or find some workarounds. We didn’t even have to contribute, but for a few issue that we opened at 3r-3268. GitHub
, they very quickly answered, told what and how to do.
 3r3308.
 3r3308. Problems, however, arise because on the Canvas you are left without all that HTML and CSS provide. You have to write all the markup and layout yourself manually in coordinates, there is no Flexbox and no block layout, and the layout takes a lot of time. There is no text handling or user input. We will soon have input fields directly on the Canvas, this is done through the hack: when you click on this text on the Canvas, the textarea is drawn on top of it, it scales through the CSS scale and emulates about the same position and the same text size user remains unnoticed: he as if in a Canvas writes something, and in fact he has a layer drawn on top of it in HTML.
 3r3308.
 3r3308. Another interesting thing was that I had to remember mathematics. For example, Pixi makes it possible to draw some lines, Bezier curves, we have objects on the Flow Chart connected by such smooth lines. But they didn’t consider it very necessary to make these lines somewhat interactive, so that standard events worked for them: mouse hovering, clicks, and so on. And in order to calculate the area that the line occupies, we had to remember mathematics, trigonometry and learn to draw polygons around Bezier curves in order to create these interactive areas. It was fun.
 3r3308.
 3r3308. - Question at last. Probably, among the readers of the interview there are developers who do not understand how much a job in a startup would suit them. According to the interview, they could already draw some conclusions, but would you like to tell them something else?
 3r3308.
 3r3308. - Probably, a startup is good for those who are willing to constantly learn. If you want a quiet job, when you learned to do one thing and are ready to repeat it over the years with a few changes, this is not about us. There will always have to develop, learn something new, apply new technologies.
 3r3308.
 3r3308. And one more thing: it will sound like some kind of cliche phrase, but if there is a desire to change something in the world and achieve something, then this is in time for startups, the places where new products or technologies are created. I personally like this situation, which has developed among us, very much to my liking. But at the same time, I have tremendous respect and understanding towards people who build and support already existing products, some large volumetric enterprise solutions. This is also great, it is a great job, which also affects a large number of users and every day makes their life easier, better, more convenient. But still, if you want development, if you want achievements, then I think this is about a startup.
 3r3308.
 3r3308. 3r3304. 3r3308. 3r3308. 3r3308. 3r33333. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e.parentNode.insertBefore (r, e)}; "[object Opera]" == e.opera? a.addEventListener? a.addEventListener ("DOMContentLoaded", d,! 1): e.attachEvent ("onload", d ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () (); 3r3302. 3r3308. 3r3304. 3r3308. 3r3308. 3r3308. 3r3308.
+ +1 -

Add comment