CTOcast # 5: “For a good discussion, you don’t need a thousand people”
Introducing the fifth issue of the podcast on technology, processes, infrastructure, and people in IT companies. Today CTOcast is visited by Gene Barmash (CTO of Merchantry, co-founder of the CTO School meeting) and Evgeny Babkin (head of the development team at Merchantry).
Listen to the podcast
About our interlocutors:
Gene Barmash attended Cooper Union College (1995--1999), New York. From 1999 to 2009, he worked at Trilogy Software, Symantec, Infusion Development, and Alfresco, moving from software engineer to technical director. In 2009, he founded the company EnergyScoreCards (a service for comparing the energy performance of buildings). Today, he is CTO at Merchantry (SaaS-platform for e-commerce).
Since 2006, has been actively involved in mentor programs and accelerators for technology startups. He is the co-founder and organizer of the rally CTO School (New York), which is a community of technical leaders with more than 1,600 members.
Evgeny Babkin graduated from Novosibirsk State University (2004), where since 2000 he worked as an infrastructure engineer. Since 2005 - at Ixtens. Today, he is the leader of the development team that is working on the e-commerce SaaS platform for Merchantry.
Alexander Astapenko: Gin, please tell us a little about yourself and your career.
Gene Barmash: I started my career at Trilogy in Austin, Texas. Then there was the height of startups of the first wave, 1999, and we all boiled in this sauce. Then for several years I was engaged in consulting, training, doing all sorts of interesting and not very interesting things.
At some point, I decided that I think and dream of all these startups, so it’s time to do something concrete. Alfresco — an open source content management application — was my first full-time startup. I was somewhere around 70th person. After that, EnergyScoreCards, where I became the founder, and my friend was an expert on the energy use of residential buildings.
Over the past year and a half, I have been leading technology at Merchantry. Since, in addition to the head of our product, I am the only technical person in the team in New York, my role is to understand what the business wants from us and present it to our technical teams as efficiently as possible, sometimes build some kind of technical strategy . And, on the other hand, understand what the technical team needs. The second part of my work is our data center and everything that happens there.
Alexander Astapenko: Zhenya, how did you get into Merchantry? What did you do before?
Evgeny Babkin:I started to work and study at the very beginning of the 2000s. If someone remembers, at that time there was a crisis and everything was quite complicated. More precisely, in 1998 I started. He worked as an administrator and I had some part of the university infrastructure, as well as several small companies where I did everything I needed.
Time passed, and at some point I got a Java developer at Ixtens, where we did large electronic stores. Then the Intershop enterprise platform was very popular. And on this platform for customers from the USA and Europe we did, as it was then called, Internet portals where e-commerce of that time was carried out.
Then our customers wanted integration with Amazon to sell, including, there. From this moment, both the company and the product have changed. We began to do integration with Amazon, then with eBay. We have our own platform, which was engaged in these integrations for customers of various sizes. Events began to develop even more interestingly: we began to advise those who wanted to make their own small Amazon, their own marketplace. At some point, we started making our product, a platform that allowed any more or less large retailer to make Amazon. Now we go a little further and want to occupy another niche in the market, so the product for this business is also changing.
I started as a developer, then I was an analyst. And now, we are working with Gene on the current version of the platform. One and the same product has been written for many years, and when the market segment changes, business changes, we get quite bizarre layers, which are then very interesting to deal with.
Alexander Astapenko: What does Merchantry do? I would like to understand what the business consists of before we talk about the technical part. Who are the customers? When did the company appear?
Gene Barmash: The company was founded about ten years ago. For the first six to seven years, we were mainly engaged in consulting. We worked for large clients and made them client applications. About three or four years ago, we took money from investors and said that we would build the platform.
We originally built a platform for marketplaces to make online markets. What is needed for this? Firstly, to be able to take products from suppliers and integrate them through, for example, the API. This makes it possible to import products into our platform and then export them to customers who have a marketplace. Buyers go to the marketplace and see products from different suppliers. When they buy these products, after some time they receive a package, which may consist, say, of 5 different things from 5 different suppliers. In the first part, we must model, synchronize and describe the products. Or, more specifically, giving our suppliers the tools to do this. Then synchronize it to the marketplace, and when orders arrive, it is correct to electronically deliver these orders to suppliers. These are marketplaces.
What we are doing now is called product information management. It looks, frankly, very, very similar. We have a platform where suppliers can add their products, and we allow these products to be exported to their store. When orders arrive, we give these orders to suppliers, synchronize information (which package and when it was sent, what number this package has) and allow us to cancel the order.
Pavel Pavlov: What forces managed to build such a product? How is the team structured? Where is?
Evgeny Babkin:Now 13 people are working on the main platform. In fact, they are one team. This is not to say that this is an overgrown team, but something similar. At different times, the number of developers, testers and everyone who worked on the platform and its integration reached probably 100 people. Now what we do and how we work is a bit like scrum. Pure scrum is not possible with us, because the product owner is far enough away from us and speaks English, and the development team in English does not speak very well. We have sprints, and thanks to Gene, continuous integration has developed quite well.
Pavel Pavlov: Can you tell how many people are in the development team? Technical support?
Gene Barmash:About 30 people work in Novosibirsk. As Zhenya said, 13 is on the main development. Also, 5-6 people work for professional services, consultants who support their product for integration. Our support consists of 6-7 people. They talk to customers, look at systems and so on. And 3-4 people are engaged in DevOps: they monitor our data center, make transformations and migrations.
Pavel Pavlov: Since we’ve hooked on this topic, can you talk about your data center? Where is the platform located and deployed at all?
Gene Barmash: Now we have two main data centers. There is such a company Connectria in St. Louis (Missouri) with a good level of service — our main production is located there. We also have a secondary data center at OVH, in Montreal, Canada. We use it mainly for internal systems. Plus, there are several production systems. And we also have a geographic failover in Amazon Web Services (AWS) in case a meteorite falls in Missouri.
Pavel Pavlov: Why not use Amazon as your main platform?
Gene Barmash:A few reasons. Partly, because it happened. We have a rather large load, and we believe that it is more economical to use our iron. Every time we looked at Amazon prices, they were significantly higher, especially the hardware that we needed. In principle, we could switch to Amazon, but a rather big transformation would be required, because we have already done everything, we have hardware. On the other hand, it would cost substantially more than what we are paying now, and we are already paying quite a bit.
Alexander Astapenko:Gene, you are communicating with a fairly large number of technical leaders at CTO School. If we talk about approaches to infrastructure, is it now a general trend for services with high loads to use data centers that are not connected with well-known cloud providers such as AWS? Or are people still inclined towards cloud services?
Gene Barmash:Mostly inclined to cloud services. I also want to note that our load is quite stable. It may be large, but there is no such thing that next month the load will be 5 times more and you need 5 times more servers. So we can do very specific capacity planning and the cloud does not give us those advantages as, for example, to other companies. Beginning startups, of course, do it on the cloud. They use Amazon or something like Heroku, which I also used for almost a year. It is terribly convenient, especially if you do things like Ruby on Rails. You don’t have to think about deployment at all.
We have a rather complicated infrastructure: we have our own FTP, email server, LDAP for users and so on. Therefore, having everything client work for us is not bad. Yes, and initially complete control over the iron was very convenient.
Evgeny Babkin: We approach the infrastructure about the same as it is customary to do in the clouds. When we deploy something, then all this is automated. Our test environments and our production environments are now fairly similar. That is, from this point of view, it does not matter whether the cloud or not the cloud, your own hosting. Everywhere you need to look at the load, you need to look at the SLA.
Gene Barmash: Yes, Zhenya is completely right, we have a lot of automation. Continuous integration provides automation, Puppet, which allows you to deploy clusters, we have Docker, which can lift services very quickly. Now we are finishing the migration to Docker and then in general everything will be unified. Developers will be able to deploy full-fledged wizards, which are 100% the same as in production.
Pavel Pavlov:Question about transition to continuous integration and implementation of Docker. How to implement? How did this help solve the problems?
Gene Barmash: We approached Docker from thecontinuous deployment side first. What is continuous deployment? This is when each commit is diplomatic on production. We don’t need every commit, so we do it once a day.
He contacts the Docker with the migration process to a continuous deployment, because Docker helped isolate our environment in a test environment and provide 100% isolation between different tests. This means that we can test different branches completely separately from each other. Each developer sits on his own branch and fully scrolls through all the tests.
Pavel Pavlov: And with what was your transition to Docker connected?
Gene Barmash:Honestly, we did not have a huge problem that we were solving at the time of the transition to Docker. We looked that there is a new technology and it seems to be suitable for us. What is a docker? This is Linux in a container that provides lightweight isolation between different servers. What gives VMware, but at a lower cost.
When we got to know the technology pretty well, we began to think about how to switch to continuous deployment. And Docker became one of the tools we used to implement this.
Pavel Pavlov: Was such a transition to be coordinated with business? Or people who invest in a project and don’t look at such things?
Gene Barmash:There was no need to ask for money for Docker, as this is an open-source project. The technology works and makes our DevOps efficient. Why not apply it?
When we switched to continuous deployment, then it was already necessary to explain to the business, because everything changed. It was necessary to distract the main development team and invest a lot in tests. We already had good tests, but we connected developers to writing functional tests. And it was necessary to tell the business that the next two weeks the team will do something else. And, accordingly, when you tell them these things, they ask: “What will they do?” And you explain that the process is changing, that the goal is to improve the quality, make the release faster. Eugene, tell me how it looked. You were much closer.
Evgeny Babkin:Yes. I would like to open this topic on the other hand. We wrote this platform for a long time. We had to deal with enterprise-clients who have some special quality requirements, and therefore we wanted to achieve platform stability. We knew what we needed to do, and when we carried out the next shift, we began to write automatic tests. That is, all of our testing was duplicated by automation. It is clear that it is impossible to automate everything, but much has been automated.
By and large, now we have two levels of tests. These are classic GUnit tests and Selenium integration tests, which are also launched through GUnit and work through external application interfaces, through a browser simulation and so on.
We wrote a massive test suite. Naturally, there were problems with how long they lasted. And they were carried out for a long time. I had to live with it somehow. We had TeamCity as an integration server, several machines that were servers and on which we deployed the whole thing. The trouble was that the master was constantly disassembled. Switching to Docker allowed us to solve this problem, because now we very quickly and easily deploy the application from scratch for any brunch, filling it with data and running tests. The work paradigm has changed completely. Now we really always have a stable master. That is, dockers have radically changed the level of quality that we have. Now you don’t have to make any compromises when the release is needed the day after tomorrow and when the not-so-terrible bugs are not bugs at all, because there is nowhere to go.
Alexander Astapenko: Gin, do I understand correctly that you do not have manual testing at all? That is, all tests — functional testing?
Gene Barmash: No, this is wrong. We have three testers: one fully works on automation and two combine manual tests and help with automation.
Before switching to continuous delivery, our testers did the tests only manually, but there was one person who chased the team and tried to do test automation. He always lagged behind, as there were 9 developers, and he alone. It turned out that many features did not have automation. Due to the fact that he always lagged behind us, regression appeared only a few weeks after the initial release. It was unpleasant. Therefore, we have included developers in writing tests.
Alexander Astapenko: I see. Eugene, will you add anything else?
Evgeny Babkin: We do not have manual recourse. That's right to say. We have manual testing, because everything is very expensive to automate. How, in fact, to automate, and then run these tests every time. But the regression is completely automatic. Each new feature is tested manually.
It so happened that a set of Selenium tests began to be written by testers and they wrote them as best they could. Therefore, at some point, we began to connect developers to writing tests, which is not easy to do. Because developers don’t really want to, it’s hard for them to work with the code that testers wrote the previous two years. They want to rewrite almost the entire code, and no one gives them. If I did this a second time, I probably would have made it so that the developers from the very beginning wrote tests on the cases that testers give. Then it would be cheaper and a little faster.
Alexander Astapenko: I already mentioned briefly at the beginning of our CTO School Meetup podcast. I heard from several people about this mitap, but I still know little about it. What is CTO School Meetup?
Gene Barmash: This is a simple mitap in New York. Although there is one now in Australia, Melbourne. We just gather once a month, sometimes twice a month, and try to talk on different topics, about how to become the best technical leader.
From my point of view, this requires competence in three areas: technology, you need to understand the various development processes so that people work effectively with each other, and you also need to be a leader in order to motivate people, conduct interviews, and so on. When we gather, I try to balance different topics in all these areas.
I hope that when people come to us, they learn something. We have a large meeting, usually once a month, when someone prepares a speech on a specific topic: how to hire people, how to optimize the process. About 100-150 people come. There is also a second type of meeting. This is about 20 people. We sit around the table and share experiences in a more intimate setting. We also have a sheet where people ask questions, while others answer them.
I’ve been doing mitap for 4 years and it’s very interesting for me, it helps me gain experience from other people. And I think that people are also interested in knowing what problems others have.
Alexander Astapenko:Gene is actually a great idea. If I had the opportunity to attract the best technical minds of New York to solve my problems, that would be cool. What are the tech leaders on the East Coast talking about right now? As I understand it, in addition to thematic speeches, there are also some conversations on the sidelines. What topics are hot right now?
Gene Barmash:What is hot is hard to say, because each company has its own problems. The topics that have been developing over the past year and a half are DevOps, the engineering culture and the philosophy of engineering teams. So I recently interviewed CTO Etsy (marketplace for handicrafts). This company is highly respected in New York. They probably have a turnover of a couple billion at the moment. The company employs about 215 engineers. And they have such a philosophy: we write PHP and such very boring technologies, on the one hand, and on the other, we don’t have to sit and think what new technologies to apply. New technologies are hard to maintain because they are new and they are changing. By the way, the founder of PHP works for them, which also helps.
And on the other hand, there are Gill that make microservices. Microservices, Docker and event-driven architecture are becoming very popular. By technology, we can say that Node.js has risen to its feet now in New York and Go is starting to be popular.
Alexander Astapenko: A few words at the end of our podcast?
Gene Barmash:First of all, thank you very much for inviting us. From my own experience in organizing meetings, I would say that if there is a topic that is really interesting to people, then you can expand it anywhere. I know that Zhenya has a group of technical leaders in Novosibirsk in which he participates. The fact that there are a lot of people in New York, it certainly helps. But if there is interest, it can be raised everywhere. For a good discussion, you do not need 1,000 people. You need 10 who are smart and who understand the same thing as you. Even less than 10 is also normal.
Evgeny Babkin:In fact, I am very pleased that such Russian-language meetings as CTOcast appear. You can often hear that Russian developers are some of the best developers in the world. It is clear that we all perfectly understand English and can do speeches in English, but listening to them in Russian is still very nice.
Listen to the podcast
About our interlocutors:
Gene Barmash attended Cooper Union College (1995--1999), New York. From 1999 to 2009, he worked at Trilogy Software, Symantec, Infusion Development, and Alfresco, moving from software engineer to technical director. In 2009, he founded the company EnergyScoreCards (a service for comparing the energy performance of buildings). Today, he is CTO at Merchantry (SaaS-platform for e-commerce).
Since 2006, has been actively involved in mentor programs and accelerators for technology startups. He is the co-founder and organizer of the rally CTO School (New York), which is a community of technical leaders with more than 1,600 members.
Evgeny Babkin graduated from Novosibirsk State University (2004), where since 2000 he worked as an infrastructure engineer. Since 2005 - at Ixtens. Today, he is the leader of the development team that is working on the e-commerce SaaS platform for Merchantry.
Text version of the podcast
Alexander Astapenko: Gin, please tell us a little about yourself and your career.
Gene Barmash: I started my career at Trilogy in Austin, Texas. Then there was the height of startups of the first wave, 1999, and we all boiled in this sauce. Then for several years I was engaged in consulting, training, doing all sorts of interesting and not very interesting things.
At some point, I decided that I think and dream of all these startups, so it’s time to do something concrete. Alfresco — an open source content management application — was my first full-time startup. I was somewhere around 70th person. After that, EnergyScoreCards, where I became the founder, and my friend was an expert on the energy use of residential buildings.
Over the past year and a half, I have been leading technology at Merchantry. Since, in addition to the head of our product, I am the only technical person in the team in New York, my role is to understand what the business wants from us and present it to our technical teams as efficiently as possible, sometimes build some kind of technical strategy . And, on the other hand, understand what the technical team needs. The second part of my work is our data center and everything that happens there.
Alexander Astapenko: Zhenya, how did you get into Merchantry? What did you do before?
Evgeny Babkin:I started to work and study at the very beginning of the 2000s. If someone remembers, at that time there was a crisis and everything was quite complicated. More precisely, in 1998 I started. He worked as an administrator and I had some part of the university infrastructure, as well as several small companies where I did everything I needed.
Time passed, and at some point I got a Java developer at Ixtens, where we did large electronic stores. Then the Intershop enterprise platform was very popular. And on this platform for customers from the USA and Europe we did, as it was then called, Internet portals where e-commerce of that time was carried out.
Then our customers wanted integration with Amazon to sell, including, there. From this moment, both the company and the product have changed. We began to do integration with Amazon, then with eBay. We have our own platform, which was engaged in these integrations for customers of various sizes. Events began to develop even more interestingly: we began to advise those who wanted to make their own small Amazon, their own marketplace. At some point, we started making our product, a platform that allowed any more or less large retailer to make Amazon. Now we go a little further and want to occupy another niche in the market, so the product for this business is also changing.
I started as a developer, then I was an analyst. And now, we are working with Gene on the current version of the platform. One and the same product has been written for many years, and when the market segment changes, business changes, we get quite bizarre layers, which are then very interesting to deal with.
About Merchantry
Alexander Astapenko: What does Merchantry do? I would like to understand what the business consists of before we talk about the technical part. Who are the customers? When did the company appear?
Gene Barmash: The company was founded about ten years ago. For the first six to seven years, we were mainly engaged in consulting. We worked for large clients and made them client applications. About three or four years ago, we took money from investors and said that we would build the platform.
We originally built a platform for marketplaces to make online markets. What is needed for this? Firstly, to be able to take products from suppliers and integrate them through, for example, the API. This makes it possible to import products into our platform and then export them to customers who have a marketplace. Buyers go to the marketplace and see products from different suppliers. When they buy these products, after some time they receive a package, which may consist, say, of 5 different things from 5 different suppliers. In the first part, we must model, synchronize and describe the products. Or, more specifically, giving our suppliers the tools to do this. Then synchronize it to the marketplace, and when orders arrive, it is correct to electronically deliver these orders to suppliers. These are marketplaces.
What we are doing now is called product information management. It looks, frankly, very, very similar. We have a platform where suppliers can add their products, and we allow these products to be exported to their store. When orders arrive, we give these orders to suppliers, synchronize information (which package and when it was sent, what number this package has) and allow us to cancel the order.
Pavel Pavlov: What forces managed to build such a product? How is the team structured? Where is?
Evgeny Babkin:Now 13 people are working on the main platform. In fact, they are one team. This is not to say that this is an overgrown team, but something similar. At different times, the number of developers, testers and everyone who worked on the platform and its integration reached probably 100 people. Now what we do and how we work is a bit like scrum. Pure scrum is not possible with us, because the product owner is far enough away from us and speaks English, and the development team in English does not speak very well. We have sprints, and thanks to Gene, continuous integration has developed quite well.
Pavel Pavlov: Can you tell how many people are in the development team? Technical support?
Gene Barmash:About 30 people work in Novosibirsk. As Zhenya said, 13 is on the main development. Also, 5-6 people work for professional services, consultants who support their product for integration. Our support consists of 6-7 people. They talk to customers, look at systems and so on. And 3-4 people are engaged in DevOps: they monitor our data center, make transformations and migrations.
About technology
Pavel Pavlov: Since we’ve hooked on this topic, can you talk about your data center? Where is the platform located and deployed at all?
Gene Barmash: Now we have two main data centers. There is such a company Connectria in St. Louis (Missouri) with a good level of service — our main production is located there. We also have a secondary data center at OVH, in Montreal, Canada. We use it mainly for internal systems. Plus, there are several production systems. And we also have a geographic failover in Amazon Web Services (AWS) in case a meteorite falls in Missouri.
Pavel Pavlov: Why not use Amazon as your main platform?
Gene Barmash:A few reasons. Partly, because it happened. We have a rather large load, and we believe that it is more economical to use our iron. Every time we looked at Amazon prices, they were significantly higher, especially the hardware that we needed. In principle, we could switch to Amazon, but a rather big transformation would be required, because we have already done everything, we have hardware. On the other hand, it would cost substantially more than what we are paying now, and we are already paying quite a bit.
Alexander Astapenko:Gene, you are communicating with a fairly large number of technical leaders at CTO School. If we talk about approaches to infrastructure, is it now a general trend for services with high loads to use data centers that are not connected with well-known cloud providers such as AWS? Or are people still inclined towards cloud services?
Gene Barmash:Mostly inclined to cloud services. I also want to note that our load is quite stable. It may be large, but there is no such thing that next month the load will be 5 times more and you need 5 times more servers. So we can do very specific capacity planning and the cloud does not give us those advantages as, for example, to other companies. Beginning startups, of course, do it on the cloud. They use Amazon or something like Heroku, which I also used for almost a year. It is terribly convenient, especially if you do things like Ruby on Rails. You don’t have to think about deployment at all.
We have a rather complicated infrastructure: we have our own FTP, email server, LDAP for users and so on. Therefore, having everything client work for us is not bad. Yes, and initially complete control over the iron was very convenient.
Evgeny Babkin: We approach the infrastructure about the same as it is customary to do in the clouds. When we deploy something, then all this is automated. Our test environments and our production environments are now fairly similar. That is, from this point of view, it does not matter whether the cloud or not the cloud, your own hosting. Everywhere you need to look at the load, you need to look at the SLA.
Gene Barmash: Yes, Zhenya is completely right, we have a lot of automation. Continuous integration provides automation, Puppet, which allows you to deploy clusters, we have Docker, which can lift services very quickly. Now we are finishing the migration to Docker and then in general everything will be unified. Developers will be able to deploy full-fledged wizards, which are 100% the same as in production.
Pavel Pavlov:Question about transition to continuous integration and implementation of Docker. How to implement? How did this help solve the problems?
Gene Barmash: We approached Docker from thecontinuous deployment side first. What is continuous deployment? This is when each commit is diplomatic on production. We don’t need every commit, so we do it once a day.
He contacts the Docker with the migration process to a continuous deployment, because Docker helped isolate our environment in a test environment and provide 100% isolation between different tests. This means that we can test different branches completely separately from each other. Each developer sits on his own branch and fully scrolls through all the tests.
Pavel Pavlov: And with what was your transition to Docker connected?
Gene Barmash:Honestly, we did not have a huge problem that we were solving at the time of the transition to Docker. We looked that there is a new technology and it seems to be suitable for us. What is a docker? This is Linux in a container that provides lightweight isolation between different servers. What gives VMware, but at a lower cost.
When we got to know the technology pretty well, we began to think about how to switch to continuous deployment. And Docker became one of the tools we used to implement this.
Pavel Pavlov: Was such a transition to be coordinated with business? Or people who invest in a project and don’t look at such things?
Gene Barmash:There was no need to ask for money for Docker, as this is an open-source project. The technology works and makes our DevOps efficient. Why not apply it?
When we switched to continuous deployment, then it was already necessary to explain to the business, because everything changed. It was necessary to distract the main development team and invest a lot in tests. We already had good tests, but we connected developers to writing functional tests. And it was necessary to tell the business that the next two weeks the team will do something else. And, accordingly, when you tell them these things, they ask: “What will they do?” And you explain that the process is changing, that the goal is to improve the quality, make the release faster. Eugene, tell me how it looked. You were much closer.
Evgeny Babkin:Yes. I would like to open this topic on the other hand. We wrote this platform for a long time. We had to deal with enterprise-clients who have some special quality requirements, and therefore we wanted to achieve platform stability. We knew what we needed to do, and when we carried out the next shift, we began to write automatic tests. That is, all of our testing was duplicated by automation. It is clear that it is impossible to automate everything, but much has been automated.
By and large, now we have two levels of tests. These are classic GUnit tests and Selenium integration tests, which are also launched through GUnit and work through external application interfaces, through a browser simulation and so on.
We wrote a massive test suite. Naturally, there were problems with how long they lasted. And they were carried out for a long time. I had to live with it somehow. We had TeamCity as an integration server, several machines that were servers and on which we deployed the whole thing. The trouble was that the master was constantly disassembled. Switching to Docker allowed us to solve this problem, because now we very quickly and easily deploy the application from scratch for any brunch, filling it with data and running tests. The work paradigm has changed completely. Now we really always have a stable master. That is, dockers have radically changed the level of quality that we have. Now you don’t have to make any compromises when the release is needed the day after tomorrow and when the not-so-terrible bugs are not bugs at all, because there is nowhere to go.
Alexander Astapenko: Gin, do I understand correctly that you do not have manual testing at all? That is, all tests — functional testing?
Gene Barmash: No, this is wrong. We have three testers: one fully works on automation and two combine manual tests and help with automation.
Before switching to continuous delivery, our testers did the tests only manually, but there was one person who chased the team and tried to do test automation. He always lagged behind, as there were 9 developers, and he alone. It turned out that many features did not have automation. Due to the fact that he always lagged behind us, regression appeared only a few weeks after the initial release. It was unpleasant. Therefore, we have included developers in writing tests.
Alexander Astapenko: I see. Eugene, will you add anything else?
Evgeny Babkin: We do not have manual recourse. That's right to say. We have manual testing, because everything is very expensive to automate. How, in fact, to automate, and then run these tests every time. But the regression is completely automatic. Each new feature is tested manually.
It so happened that a set of Selenium tests began to be written by testers and they wrote them as best they could. Therefore, at some point, we began to connect developers to writing tests, which is not easy to do. Because developers don’t really want to, it’s hard for them to work with the code that testers wrote the previous two years. They want to rewrite almost the entire code, and no one gives them. If I did this a second time, I probably would have made it so that the developers from the very beginning wrote tests on the cases that testers give. Then it would be cheaper and a little faster.
About CTO School
Alexander Astapenko: I already mentioned briefly at the beginning of our CTO School Meetup podcast. I heard from several people about this mitap, but I still know little about it. What is CTO School Meetup?
Gene Barmash: This is a simple mitap in New York. Although there is one now in Australia, Melbourne. We just gather once a month, sometimes twice a month, and try to talk on different topics, about how to become the best technical leader.
From my point of view, this requires competence in three areas: technology, you need to understand the various development processes so that people work effectively with each other, and you also need to be a leader in order to motivate people, conduct interviews, and so on. When we gather, I try to balance different topics in all these areas.
I hope that when people come to us, they learn something. We have a large meeting, usually once a month, when someone prepares a speech on a specific topic: how to hire people, how to optimize the process. About 100-150 people come. There is also a second type of meeting. This is about 20 people. We sit around the table and share experiences in a more intimate setting. We also have a sheet where people ask questions, while others answer them.
I’ve been doing mitap for 4 years and it’s very interesting for me, it helps me gain experience from other people. And I think that people are also interested in knowing what problems others have.
Alexander Astapenko:Gene is actually a great idea. If I had the opportunity to attract the best technical minds of New York to solve my problems, that would be cool. What are the tech leaders on the East Coast talking about right now? As I understand it, in addition to thematic speeches, there are also some conversations on the sidelines. What topics are hot right now?
Gene Barmash:What is hot is hard to say, because each company has its own problems. The topics that have been developing over the past year and a half are DevOps, the engineering culture and the philosophy of engineering teams. So I recently interviewed CTO Etsy (marketplace for handicrafts). This company is highly respected in New York. They probably have a turnover of a couple billion at the moment. The company employs about 215 engineers. And they have such a philosophy: we write PHP and such very boring technologies, on the one hand, and on the other, we don’t have to sit and think what new technologies to apply. New technologies are hard to maintain because they are new and they are changing. By the way, the founder of PHP works for them, which also helps.
And on the other hand, there are Gill that make microservices. Microservices, Docker and event-driven architecture are becoming very popular. By technology, we can say that Node.js has risen to its feet now in New York and Go is starting to be popular.
Alexander Astapenko: A few words at the end of our podcast?
Gene Barmash:First of all, thank you very much for inviting us. From my own experience in organizing meetings, I would say that if there is a topic that is really interesting to people, then you can expand it anywhere. I know that Zhenya has a group of technical leaders in Novosibirsk in which he participates. The fact that there are a lot of people in New York, it certainly helps. But if there is interest, it can be raised everywhere. For a good discussion, you do not need 1,000 people. You need 10 who are smart and who understand the same thing as you. Even less than 10 is also normal.
Evgeny Babkin:In fact, I am very pleased that such Russian-language meetings as CTOcast appear. You can often hear that Russian developers are some of the best developers in the world. It is clear that we all perfectly understand English and can do speeches in English, but listening to them in Russian is still very nice.