Ivan Gekht | Oct 10, 2024

[00:00:00] Speaker A: Ivan, welcome aboard to the show. Today, we're going to have a very geeky discussion today, but what I'd like for us both to try to do is to keep it as if we're talking to our grandmother and really stay at the basics. I wanted to start, first of all, with an introduction. What do you actually do for a living? [00:00:20] Speaker B: I solve problems for a living. [00:00:23] Speaker A: Solve problems by developing software. [00:00:27] Speaker B: Usually. [00:00:28] Speaker A: Perfect. Okay. So I just want to position the audience to stay with us. Companies keep me honest here from around the world, come to you because you're an expert in developing software and you help them by developing that software through, I think you have more than ten locations around the world where you have developer teams and you can basically help companies execute their, let's say, software dream. Is that a fair description? [00:00:57] Speaker B: Yeah. We're in 13 countries right now. Our people are located in, and we help businesses achieve their business goals mostly through software. Right. But again, the software is a tool here. So we are experts at problem solving rather than developing software. [00:01:18] Speaker A: Okay, so that's not what I would expect. Right. So I would expect a software development company. You come to them, you tell them what you want, and they develop it. So why are you insisting on we solve problems versus, like, if I tell you develop this for me, will you say no? [00:01:33] Speaker B: I might. [00:01:34] Speaker A: Okay, that's super interesting. Okay, let's lean into this. Why might you tell a customer no? [00:01:40] Speaker B: You know, we build long term relationships and partnership with our customers. Right. So the longest customer we have right now, we've been working together for 25 years. They considered us kind of part of the team. Even though we are not out staffing, we do certain projects for them continuously. We did over 100 different projects for them. And the way to build that relationship is based on trust and results. If you come to me with the solution that I know won't solve the problems that you have, but you insist on developing it, I'd rather say no because I don't want to take your money and do something that won't help you. [00:02:26] Speaker A: That is so refreshing and delightful. I really appreciate that perspective. I want to dive into this a little bit more. Is the disagreement or the, let's say, collaborative disagreement with the customers? Is it just on the technical side because customers are making technical requirements from you, or is it also on the business side? [00:02:48] Speaker B: On the business side as well? [00:02:51] Speaker A: What is the, let's say, level of due diligence or thinking that you're doing with your customers on the business side? [00:02:57] Speaker B: It highly depends on the project. It sometimes it starts with a simple, like, hey, guys, I looked through your business plan. I checked out the math, and it's not checking out, like, what are you gonna do with this and this and this, right? And sometimes these conversations are like, oh, wow, we didn't think about that. So with some customers, it's like, right now, I have a project where my team is going and doing the competitors analysis and a lot of other things like analytics and everything to make sure we know where the problem is if the customer not sure. [00:03:37] Speaker A: Wonderful. That's quite unusual for what might be perceived as an engineering team to do a competitive analysis. [00:03:45] Speaker B: It is. Well, it is, and it isn't right, because by definition, that's what engineers do. They solve problems again within their fields, usually, right? But they do work to bring value to wherever they work. It's just historically, we had so much business available in software because the industry grew so fast that a lot of businesses stepped in just to fill in the gap without having an engineering background. [00:04:20] Speaker A: Okay, so here. [00:04:22] Speaker B: Yeah, go ahead. [00:04:23] Speaker A: Here's what I would argue. What you're saying now is incredibly important, and it is not at all common. In fact, I would argue that in the many organizations that I've seen, engineering is. And this is, I'm talking about not offshoring, outsourcing, like what you're doing, but I'm talking about an organic, a company that has its own engineering group. The expectations from the engineering group is just write the code. My argument in every organization I've been in is that these are highly intelligent people, and the more that you involve them in educating them and sharing with them the business processes, the competitive landscape, the more insight and value they will bring into the engineering process and the more productive discourse you will have with the engineering team. So I think that you have a really unique insight that is not at all common. How is that? Let's jump a little bit into the processes. What does the engineering process look like between a customer has a requirement and the engineering team actually starts writing code? What does that look like? What does that include? [00:05:32] Speaker B: You said that the first step is customer give some kind of requirement, and that's not true, right? Because we need to look at the entire, entire value stream. Software development is just a part of the value stream of any organization. And the value stream doesn't start with requirements. It actually starts with the customer and it ends with the customer. And everything that happens in between has to be aligned. That's why the conversation of, like, let's use technical team just to write code is the same as, like, hey, let's use marketing only to do ads. Let's not talk to sales about what the customer experience is. Let's not talk to customer support representatives. Right. Because they have no knowledge of the customer issues. So, yeah, when you look at the entire value stream, that's where you start setting up the process to actually generate some kind, kind of value for the organizations and for your customers through software development. [00:06:37] Speaker A: Okay, so this is absolutely wonderful. What are these things? How do we identify? Or what do we need to identify when it comes to, how are we going to make sure that this is actually going to drive value to the customer, to the end user? [00:06:54] Speaker B: Yeah. That's where things like design thinking comes in. Right? Design thinking is a process that you can apply before any kind of development starts. Right? Have empathy to your user. Like observe, learn, see what they do, see what your top users are doing. That's usually what's required by the rest of them. Like all of that kind of stuff. See what workarounds they found. Then kind of do the journey, the mapping, the entire outline, the entire customer experience. Focus on customer experience. And then you can start, like doing proof of concerting and all of that kind of stuff. But I was listening to a podcast with one of the Netflix founders, and he gave a great example. The way to validate the idea. You don't really have to do a lot of things. You can do it with a piece of paper and a pen and just going out and asking people, that's what needs to happen. [00:07:53] Speaker A: Okay, so you've said three absolutely delightful things, which I think most executives are not familiar with. One is a voice of customer program. Really? That was the first part of your comment. The second one is journey mapping. Incredibly important, I think highly undervalued or underappreciated concept. The other one, the third one and last one is the MVP process. And you highlighted a point that is also incredibly important. You don't necessarily even have to write code. And even if you do write code, it doesn't have to be a version that you're even going to use. It can be almost smoke and mirrors or prototyping. So I want to step through these three items because I think they're incredibly important. And I would argue, and we can see if you agree, that these three steps are not very commonly used today in industry. And I think they definitely have a place for executives to have more understanding on. So let's start with voice of customer. The purpose of voice of customer is to have a true ongoing feedback and insights from your customers and I would even extend that also to internal teams, customer success, sales, etcetera. What this is doing is driving insights for the product development team. I think that part everybody gets. I think the difficult part is how do you do that? What are the tools and techniques that you've employed historically to develop these voice of customer programs, to actually connect and listen to what customers need? [00:09:36] Speaker B: A variety of things can help you here. Right? The power of observation is incredible. You can easily apply, for example, for software solutions, you can easily apply data analytics so you can track what customers are doing, which features they are using. All of that information is incredibly valuable. You can go and talk to your customers and I think this is one of the most undervalued and underused tools there is. Just listen to them. They are very vocal about everything, especially about negative things. Go out and listen and talk to them. It's important to to have everything in front of your eyes. So it's that data visualization, the dashboards, stuff like that really helps to see what's going on. [00:10:31] Speaker A: Perfect. There's analytics. Let's break that down. There's a couple types of analytics. There's actually software that you can record the keystrokes and the mouse movements of your customers. You can actually see what they're doing on your software. I've seen that work in a couple cases that can be incredibly powerful, but also at a lower level. You can record certain events in the software. You can say, anytime a customer does XYZ, I want that to be saved to the database. And then there's additional SaaS softwares that can help you analyze that. So analytics is actually way more mature and advanced than what I would say many companies, especially SMBs, are even using today. So that's such an interesting area. But I think that's kind of easy to do if you understand it and you invest in it, because you find the tools, you research them, you implement them in your code, you put a nice overlayer that can analyze them, and there's quite a few big players in that area. What's really difficult is connecting to existing customers and prospective customers and learning from them. A lot of feedback that I get from executives and leaders is that, oh, they don't want to talk to us or that they want us to make commitments and that isn't necessarily what we want to develop. And then it turns into this negotiation. What is some advice in creating, nurturing and even building these relationships with customers and prospects in order to create a good voice of customer program that will. [00:12:08] Speaker B: Drive your vision, bring them value I think that's the, the best thing you can do. And I just can give you a real life example, right? So we were developing an API for automated trading. So one of the things we did as a part of that project is we created a community. Literally, we created a website with a forum where we start publishing articles, we start doing, you know, custom requests, we start answering questions, etc, etcetera. And that community grew to something of 100,000 people, like water, who would come to that community, read, ask questions for something. Obviously, it took a few years to build it. It required investment time, money, emotional resources, obviously. But in the end, they were so unbelievably important in the project development that, you know, they brought success to the project, right? Because of the constant feedback, because of their actual willingness to like, hey, give us better version, right? We're gonna test it for you. We're gonna give you feedback right away, right before you go to the market. Just give it to us. We want to help you, right? Because we helped them at the beginning to get to know the technology and to start using it. [00:13:36] Speaker A: Amazing. I want to expand this, so, I mean, that's amazing, right? If you can create a focal point for your community to have these discussions, and then you're really listening to the community in order to drive your understanding of their needs, that's pretty amazing. What about the role of sales and marketing in helping build the right products? [00:14:00] Speaker B: I mean, both of them are on the front lines, right? So marketing can always bring invaluable insights and the things like what's going on on the market right now, what are the competitors doing? Doing? And not just what. Why are they doing this? Right. What do people say? What do people want? Do they actually show in their behaviors they want? Because what people say and what they do very often can be different things, right. With sales, it's even more so because they not just observing, they interact in every single conversation. And I think there are a lot of helpful selling frameworks that are very much focused on not selling service, but rather figuring out if that service can help your prospective customer alleviate the pain that they have, right? So if sales is really doing their jobs, very often they basically first, like a good business analyst, they learn about your customer, their problems, their pains, their issues, their processes, way more than you anticipate, right. And when they bring that back, this gives you a lot of insights in what you can do on the market. [00:15:20] Speaker A: I love that. I mean, as I listen to you talk, the, you know, I think one of the most important sales books, but I would say it extends beyond sales. That I think exists is how to make friends and influence people. And really the key statement there, it's not about you. It's not about your product. I mean, you know, I say this for me, but it's, it's such, it's so true. You see so many organizations that are me, me. This is my product. This is what I do. This is da da da. It's not about you. It's not about your product. It's about the customer. It's about their pain. It's about their challenge. It's about how you're going to drive value for them. It's such a critical and understated and everything you're saying that's coming across. So I truly appreciate that. Thank you. Moving from the step that we have an active and ongoing voice of customer and internal customer. They're also a type of customer. So we've got this inbound and outbound voice of customer. Now we want to build something. Do we just go and spend, you know, a month, ten months on building it? Or is there a step before now, we talked about this. MVP. [00:16:29] Speaker B: That's what is. MVP is a minimal, valuable product. So it's something that brings value with a minimal amount of work involved to produce. And again, in a lot of situations, it can be a very, very simple solution. It can be a change in the process. It can be be anything that brings value. [00:16:53] Speaker A: Can it have no functionality? Can it just be a mock up. [00:16:57] Speaker B: To be an MVP? No, it will be a mock up. It can be a proof of concept. Not going to be an MVP because MVP is supposed to bring value. [00:17:07] Speaker A: So let's take this in two steps. Would a mockup have value in this process, and what would that value drive? [00:17:13] Speaker B: If any mockup can give you knowledge, knowledge is hardly a value. Knowledge can save you some money by avoiding a costly mistake. Knowledge can give you the definitive answer and reduce your risks to a certain perspective. It's value, but it's a value for you. We are talking about value for the customer first and foremost. And mockup unfortunately doesn't bring value to your, to your customer. That's why it's a great first step to validate your idea that there is a pain and your customer want it solved in a certain way. But once this idea is validated, you got to give something that's actually working. [00:18:00] Speaker A: What are we trying to learn or do? Is it just the first version of the software that we put out or is there a specific purpose? [00:18:07] Speaker B: There is a longer and more complex response to that, because we have to take a step back. So there is a thing called Kinnevin framework developed by one of the IBM guys like 40 years ago or something, that defines four, actually five quadrants of complexity. So what does it mean? It means that the situations are different around us. Some problems are simple. And what does it mean that it's simple. You know exactly what to do and how to do it. Some problems are complicated. Complicated means that there are a lot of moving parts, but once you figure it out, you know exactly what to do. Like a swiss watch, you can have a hundred gears, and it looks absolutely complicated. But once you figure it out, any change you make to the system will give you a definitive change. In the outpost, then there is complex. Complexity is where the sum of parts is not exactly predictable, right. When the interactions become in a way that there is an emergent results that can be more than the sum of parts. So that's where we actually start talking about MVP's and stuff like that way more actively, because we cannot exactly predict the end result of our efforts, basically. Right. And then there is case is a completely different situation. Case and undefined is more complex, more crazy situations. [00:19:42] Speaker A: So that's absolutely wonderful, because what you've said is that there can be different reasons for us to do the MVP. And really what this is about is proving out risk. So really the first question is, what is the risk here? So you talked about scenarios where the risk can be engineering risk, where maybe there is something here in how all the components mixed together that it just won't work. So actually having an MVP where we're not doing all the functionality, we're just making sure everything fits together. That could be in some situations, the higher risk in other situations, there could be that everything is pretty much, we think we can do it, but there's this one module. Maybe it's AI, maybe it's image recognition, maybe it's an algorithm. It's just incredibly complicated. And all the risk, or a majority of the risk is in there. So let's start there. And then maybe there's a third part, which I'll elaborate on your words, because you didn't necessarily touch it, is maybe the risk is about the customer value. So giving this to the customer and saying, oh, yeah, this actually drives value. It works for us. Maybe that's a risk. So the perception of the MVP is really about removing risk from your project, from your go to market, etcetera. So I thought that was such a. Because I'm kind of pushing you into directions, and you're like, no, no, no. You need to look at the big picture. I love that. [00:21:03] Speaker B: But absolutely, I agree. One of the main purposes of MVP is to actually reduce risks. [00:21:11] Speaker A: I love that. Thank you so much for pushing back on me and saying, no, no, no, this is how you should look at it. I absolutely love that. Okay, so we figured out what the customer wants. We figured out what the risk is in the process. We put together a plan to mitigate that risk. The next step is the engineering. I want to talk about what you've seen as the big risks or big processes that need to be in place in order to have high quality software. The point that I'll make is that there's no faster way to churn your customers than to deliver software that doesn't work. So tell us about what are the tools and tactics that engineering groups are using nowadays. [00:21:59] Speaker B: Again, we have to start with Kinevn Beck. Right. And depending on the complexity of the system, if it's a simple system, if it's a complicated system, if it's a complex system, every single one of them will have different approaches that work best for the kids. We hear a lot about agile. Agile is for complex systems. Agile is actually too expensive and for simple systems, and it's too process oriented, and it's still too heavy, for example, chaotic systems. Right. So first and foremost, you need to really understand what is your situation and choose a proper tool to deal with it. Because there is a saying, like, if you have a hammer, everything starts looking like an a. It's a lot of businesses go into like, okay, we now know scrum, we know agile. Like, we're gonna do every single project agile. Why then? Quality is very often about discipline. You got to have a set of standards, and you need to follow the standards, because if you don't have the discipline to do quality work day after day, you will never get a quality product. And then with any kind of system, you focus on shortening feedback cycles. The shorter the cycle, the faster you learn about any issues, the faster you get feedback, and the cheaper it is to fix. Because the most expensive fix, if we look at the QA, the mistake on production is about, what, a thousand times? Or sometimes it can be million times more expensive than when you found it at the, for example, user scenario stage or requirement gathering stage. [00:23:57] Speaker A: Let's lean into that for a second and talk about the steps of where mistakes can happen. Software is to a large extent designed, meaning that architectural decisions are made. Code is written by the developer, after code is written by the developer, then hopefully there are different quality assurance mechanisms. Mean it goes from the developer to somebody else, and then there's a lot of automation that happens, and then it goes out into the wild, into the customers, the widely accepted and statistically financially proven time and time again is that the earlier you catch an issue, the less expensive it will be for your organization. So this is, let's say, a, I don't think there's any engineering group on earth that will disagree with that statement. So that's widely, widely accepted. So what you're saying is that the best practice is to catch your mistakes early. How do you do that? What are the tools and techniques to do that? [00:24:58] Speaker B: A lot. Right now, we are so far advanced in different methodologies than we were 20 years ago. So let's take union testing and test driven design and development. So ideally, you want to have your tests done before you write the first line of the code. Not a lot of people follow that principle. [00:25:21] Speaker A: Okay. This is actually incredibly important. I want to drill down into this. I want to challenge you. Okay, that sounds logical. You write the test before you write the code because you know what the output should be. [00:25:36] Speaker B: Yes. [00:25:36] Speaker A: What's the pitfall? When engineers write the code first and then write the tests? What happens? What's the pitfall? What goes wrong? [00:25:45] Speaker B: They test the code. [00:25:46] Speaker A: So they test what they. [00:25:48] Speaker B: Instead of testing? Yes. Instead of testing the business scenario that the code should cover. This is one of the most common mistakes that I saw over the past ten years, for sure. [00:26:02] Speaker A: Completely agree. I completely agree. So this idea is an old one. It's not as popular or been marketized, but it's an incredibly valuable one. This idea of having the tests written before the code is developed is incredibly, incredibly important. And this has been automated, this is today to a level that, as you can see, the tests being checked off as the code is written. Oh, you've got ten requirements for this module, for this piece of code. And as you write the code, you kind of like, tick, tick, tick, tick. It's almost magical in how it works. It's quite beautiful. When my engineer showed me this technology, this is not widely accepted, this process today, or is everybody doing this? [00:26:49] Speaker B: No, it's not as widely accepted as you would want it to be. And moreover, again, that differentiation that the test should be testing the business scenario, not the code that you are written or even about to write. I think this is very important because in a lot of cases, by the time that something makes it to the development, it can lose its business meaning. And this is an issue. This is something that we need to fix, because development should know about the business goal. User scenarios should cover user scenarios, not the system behavior of certain feature. We need to be constantly refocusing the engineering team and the QA and everyone involved into the basically manufacturing of the software onto the goal that they are solving or reaching. [00:27:50] Speaker A: Perfect. So test driven development, incredibly important topic. What are the other techniques that can be used to ensure high quality of output? [00:28:00] Speaker B: Static code analysis. [00:28:02] Speaker A: Okay, perfect. What is that? Let's keep this at high level for the executives. [00:28:06] Speaker B: Absolutely. What does that mean? There are software that actually can go through the code that developers written and find some mistakes based on certain patterns and stuff like that. So usually it's on an expensive side. Right. So we can easily be talking about 2030, $40,000 a year for a. Yeah, for a product that can do that, but it's extremely valuable. And I saw applications that would be written five years ago and would be above, like for example, Google bad behavior threshold in the Google Play store. And then you apply the static code analysis, you start fixing these issues, you start refactoring and clean it up, and suddenly it's way below, right? So it went from like 5% crashes to under 1% crashes for the users. And with just one tool and implementing its recommendation. [00:29:13] Speaker A: And I want to extend that, this is not only about bugs and memory leaks and the things that bring us blue screens. This is also about security. [00:29:20] Speaker B: Yes. [00:29:21] Speaker A: Okay, tell us more about that. So we'd be using this tool, it's analyzing our code and it's finding security issues. [00:29:30] Speaker B: Yes. There are a whole bunch of patterns, recommendations on how to write secure applications like Ow, ACS B, and some other standards. And if you don't follow them, you open up your application to a whole variety of different issues. Like 15 years ago, there were so many websites where, for example, you're filling out a registration form and you can pass in HTML code and it will process it and it will show it as a, I don't know, picture on your form, right. So if you are a bad guy and you want to use it, you can start using like SQL injections, go into the database, get the data out of the database and all of that kind of stuff. So these tools actually help prevent these mistakes. And in a lot of cases, the security audit, if you order it for a third party to do it, can easily run hundreds of thousands of dollars. These tools cost less. And if you dedicate it to quality and to security, you use these tools on a day to day basis. You constantly validate what you produce it, and in the end, you're going to do really well on that front. [00:30:49] Speaker A: What about code reviews? With these highly sophisticated tools, do we even need human beings? Do I need a team member to look at the code and sit together with another developer? Is that helpful? [00:31:01] Speaker B: For what? [00:31:03] Speaker A: Good question. Good question. Okay, so you're alluding to the fact that code reviews, and keep me honest here if I'm speaking for you, but you're alluding to the fact that code reviews have value beyond the code review itself, right? For example, transfer. [00:31:19] Speaker B: Absolutely. And for me, it's the primary benefit. First of all, you don't want to have Keyman dependencies. It's so called bus factor. What if the bus runs over your key developer tomorrow? What's going to happen to a project? [00:31:38] Speaker A: God forbid. [00:31:40] Speaker B: Yeah, God forbid, of course. But as a business owners, we always think about the worst case scenarios, not the best case scenarios. It's all about risk management rather than great ideas, but it's also about learning and helping others to learn. So if you have a senior level developer reviewing the code of a junior level developer, you can facilitate this little interactions of knowledge transfer, not about the projectiven knowledge, but just general software development knowledge. For example, hey, you know what? I would use this algorithm here instead of this one because of that. That, that. Right. And this helps people to grow because again, in this industry, we see too many cases of five times one year experience instead of a proper five year experience with the developers. So this is one of the tools that can help alleviate that pain. [00:32:38] Speaker A: Absolutely. I think a lot of companies put themselves against the wall with having one developer who is incredibly talented, but because of their talent, they've done so much that if one day they leave, it's going to be a catastrophe. So for sure, code reviews are one of the tactics to combat that problem. But really you're lifting up the rest of your team. And I've seen junior developers find architecture problems, not a bug in the code, but a bug in the architecture through a code review, which is incredible, because if you are now looking at somebody's code, then you're asking yourself, oh, why like this? Why like this? Why like that? And then the senior developer or the colleague is saying, like, oh, that's a, that's a really good question. And then they go to the architect and they go to the product manager, and then suddenly they're talking to me, right as I've been in a lot of leadership product management roles, and I'm like, oops, we need to rethink that. But then what did we do? The developer hasn't necessarily, you know, this has got into the customers. It hasn't gone through a QA cycle. It's really just, they haven't even committed it, meaning put it into the actual code source base, and they found a problem. So what we've done, we've shifted it from the customers being QA or customer success being QA, which is horrific and it costs a lot. We've just brought that so much earlier into the process. So I, and I think you would unequivocally support this, is, we need to bring back as much code reviews as we can across different organizations. It has tremendous value. Okay, so, you know, we've done the code review. We've committed the code to, you know, what we would call base or our source code. Now it goes through a quality assurance process. What does that look like? What do we do in quality assurance? [00:34:36] Speaker B: So I started my career in quality assurance. I was a QA specialist for many years, you know, as a test designer, then test manager, all of that stuff. But one of the most important things that I learned is at the very beginning of my path, I was told that my role as a quality assurance is not to test the code, not to test the product, is to make sure that users will have their value from whatever was developed. [00:35:11] Speaker A: Thank you. [00:35:12] Speaker B: And that is the role of quality assurance. It's the first line of defense for your customers. [00:35:19] Speaker A: That's right. So there's manual testing. That's what you started your career with. What automation have we seen since in regards to testing? [00:35:28] Speaker B: I mean, I had the pleasure of doing a lot of manual work, and it's, it's tiresome, especially when you're working on the same product for, let's say, couple of years, it can be devastating because you have to. Especially if we talk about regression. Right. So you, every major release you need, you need to make sure that everything is working. Not what just was touched, but everything is working. That we didn't break something, because that's another thing, like tidbit of something I learned, is that the error is nothing. It's when the application is not doing what it's supposed to do or it's doing what it's not supposed to do. And these are two different scenarios. Right? If the application deletes. Yeah. [00:36:16] Speaker A: This is incredibly interesting point. [00:36:18] Speaker B: Right. [00:36:18] Speaker A: So I think a lot of us who have grown up in the software industry figured out that just because you touched a certain part of the code does not mean that you did not break unintentionally other parts, the code. And it's like, oh, we didn't even touch that. And it's, well, but, you know, it affected that other point of the code. So this, this whole concept of regression testing is really about testing the entirety of the code. But that's difficult, right? Because if you've been developing for ten years, that's a lot of testing. [00:36:51] Speaker B: Yeah, well, it's not even, even if you, if you have been developing for one month and your application has, let's say, 100 different scenarios of use, you have to run through all of that time after time, time after time. And it's hard, it's hard not to miss things when you do it manually, time after time, it's very, very demanding and dulling job. That's why you want to automate as much of it as possible. But in all the reality, I don't see the QA and the development as two separate parts. It's a single team. Because the more, for example, you move towards the standards, you have, for example, different architecture patterns like solid single responsibility, all of that kind of stuff. So once you start implementing proper architecture, you're actually reducing the risk of something else break. Because one of the mistakes, if we go a little bit technical, is at the beginning of the development, very, very often developers use, for example, a single class or a single method and don't separate it by business use. They merge it together by, in program use. And then the scenarios, business scenarios change. And suddenly you have a single class working on two different scenarios and they no longer match between each other. Right. You change it for one scenario, the second scenario breaks. And that's basically, that's a breach of the architectural patterns that you should kind of follow. Right? So the more you do on the development side, the less you have to do on the QA side, that then the QA is actually, you don't need to fire the QA. The QA is there not to test the code. They are there to make sure that your users are getting what they need so they can actually be way more productive working together with the sales, with the customer support, with the marketing, and helping to define the system way better from their perspective. [00:39:07] Speaker A: Right. That's a 30 year old, more than 30 year old concept. We call it high modularity, low coupling. But I come into engineering groups nowadays and they don't necessarily know what modularity and coupling means in that concept. So it's kind of ridiculous that these fundamental truths of software development, many of them have been around for 50 years. And yet we still find gaps in lack of regression, automated regression testing, we find gaps in test to development strategies, we find gaps in these ideas that you just talked about, about coupling and modularity. And I get that this is a complicated concept for our non tech audience, but it's probably one of the most important concepts in software development. [00:39:59] Speaker B: And I think a lot of that comes from, again, this industry had so much demand in resources that the level of preparation of those who go into the industry significantly went down. And what happened is people started to learn how to code and that's it. So there are coders that. Not software developers, developers. And I can kind of attest to that. When we're doing interviewing a lot of people to hire 20 years ago, almost every single one of them knew all the basics, all the fundamentals, the knowledge of principles, algorithms, all of that kind of stuff. A lot of them didn't know how to code well, so we had to teach them how to code well, but they knew all the basics. Right now we have so many people who come in, they know how to code very, very well, and they have no idea about the fundamentals. And that's because, you know, you have so many academies and everything, like, hey, pay us $5,000, go through the code in bootcamp, we will make a JavaScript developer out of you in four weeks and we guarantee you get the job. I mean, that's great, you will get the job, but you won't get the knowledge that is necessary to actually grow and perform the job well in the long run. [00:41:20] Speaker A: Yeah, that's such an interesting point, because this was probably more than ten years ago. I had a developer who I hired, and he told me nobody would hire me. I was like, that's ridiculous, you're brilliant. And the way that I ascertained that brilliance is I put him through an algorithmic test. I forced all my developers to write algorithms which are in English, not in any specific language, and most of the, most, actually 90% of the people who went through this test, they failed. They couldn't do it. But what I saw is how fast they can think, how fast they construct your logic. So I was like, you're brilliant. And he said, yes, maybe, thank you for the compliment, but I don't know, c sharp, which is a developer language, and that's the hot thing right now. So nobody would hire me. And I told him, you know, and I don't think he'll mind for me mentioning his name. I said, eldon, you know, you can learn a new language in two weeks, and then in a month you'll be pretty good at it. But your ability to think fast, your brilliance in understanding code quickly and being able to create new structures quickly, that will make you a ten x developer versus somebody else who has five years of experience in c hash. And that is entirely not something that is a common knowledge in the market today. I'm saying that from my perspective. I'll let you also give your comment. The other thing that I'll say, and I want your feedback on this as well. The difference between a good developer and a great developer is not 30% better, it's ten x. You'll pay them 30% more, but you will get the equivalent of ten people. And I have a very simple example. When I was head of engineering for a company that was doing forensics, really what we were doing is we were taking these telephones, we were reverse engineering them and then adding them to our hardware support. Because basically this company, what it did, it created forensic evidence out of the phones. I had one guy who could do ten of these phones per week, and then I had other team members which would usually do one to two. That is just such a crazy, crazy situation, right? Like a good developer is not a little bit better. He's ten x better. That surprised me so much. What's your experience? [00:43:42] Speaker B: It's actually a little bit worse than just an x. So when we talk about like some complex, especially technologically complex tasks, it's, you can't divide by zero, right? So that's why you can't really measure the x. It's literally the difference between the person being capable of solving the problem and doing something. And not like you can waste a year and they won't figure it out, while some of the great developers can figure it out, in some cases in minutes, actually. Yeah, this kind of developers, they unicorns. Like, it's not a lot of them on the market, and you should be happy to have one or two or five in your organization. But what I would agree is that, yeah, our entire business was founded on the, it wasn't like one of the foundational concepts, but it was in the business from day one, is that if a developer cannot switch technology within one month, they're not a developer, they're a code. So that's why a lot of our developers who are old school, who started in the nineties, they all can write C, C, hash, Java, they can switch between languages like, oh, there is something on node JSDEM. Yeah, give me a day. I need to look through the documentation and then suddenly they're performing just as well as everybody else on the team, and they just saw the technology two days ago. [00:45:27] Speaker A: Ivan, what an absolute pleasure. Most of our interviews are not techy and geeky, but I think people are kind of ignoring, especially executives, the importance of good engineering processes. They don't understand enough about it. So I think this is an incredibly important topic to raise awareness to. [00:45:46] Speaker B: Just wanted to say, like a lot of people don't realize that they are no longer whatever businesses. They attack businesses. The tech started to become so important within organizations that they are no longer running whatever they think they're running. They're running a technological organization, and that doesn't necessarily mean that they have to change everything. They just have to be aware of it and pay more attention to what's going on on the tech side of things and maybe, yeah, get a little bit of knowledge and understanding of what the process is, why they are what they are, so they can lead these teams back. [00:46:24] Speaker A: Absolutely. What would. I have a difficult question for you. This is the last question we ask all our guests. [00:46:32] Speaker B: Sure. [00:46:33] Speaker A: What would you say to 20 year old Ivan? [00:46:36] Speaker B: Would you give him by bitcoin? That's an easy one. Next. [00:46:41] Speaker A: Well, not trying to hack the stock market. Good advice to your career. [00:46:46] Speaker B: I think it's embrace. Embrace the journey, not the destination. It took me quite a while to really embrace the journey instead of trying to, oh, I want to be there, then I'm going to be happy. I want to be there and I'm going to be happy. And if I stayed on that path, I would never be happy, because happiness is not in the destination. It's actually in. In the way you get in there. Yeah, I think that's the best advice I can give to myself at 20 or to any 20 year old. [00:47:20] Speaker A: I appreciate that. Ivan, thank you so much for joining the show today. I appreciate you. [00:47:25] Speaker B: Thank you, Ari. That definitely wasn't what I initially expected when I came today, and it was a wonderful conversation. I appreciate your wonderful questions. Very insightful. So thank you. [00:47:45] Speaker A: Thank you. Very kind of you to say.