 I hope you had a good lunch and I will try to wake you up a little bit after lunch with a quite philosophical talk with just a few practical examples. The gist, in the next 30 minutes, I will try to convince you that the more knowledgeable we technical people are in our projects, the more our projects suffer. Unless we seriously change our attitude towards the knowledge we possess and the way we share it with other people and the project itself. And then in the end I will demonstrate how in our company we turn knowledgeable experts into expertise providers and what is the difference. I had 37 slides, which seems like a lot but I will jump quickly through them. First of all, a little bit about myself. First I'm a programmer, this is my GitHub account and I do write code myself. So I'm more on the dev part of the DevOps pair. I have a number of open source projects just quickly. This is the DevOps continuous delivery automator for the GitHub. This one is the web framework, Java web framework. This one is the Java tools for object-oriented management of data. And this one is a collection of Java tools which I am managing for over, I don't know, five years. Anybody here is a programmer actually. Can you raise your hand? Oh that's great, I need Java programmers here. So anyone ever heard about any of these products? So you should check them out. Some of them are interesting. Second I'm a CEO of Xerocracy. That's a software company, that's a platform for developing project, developing software project where we connect customers and freelance and not freelance developers. The core of this project is that it's an AI powered project management chatbot which helps human managers coordinate software projects and even sometimes and very often it replaces them, I mean human managers for the majority of routine operations. So actually in this platform the computer manages programmers. And that's why maybe I will, the things I will explain later are applicable, very much applicable on this platform and may be applicable in your case but not all of them. And the third I'm a book writer. This is the package of my books and the recent one and the most, not the recent one but the most famous is called Elegant Objects. It's about object-oriented programming. And it's about two years old. I written it two years ago. It's quite popular for again object-oriented programmers. The last one is called Code Ahead, the one I published just three months ago which actually summarizes everything I will say today. So it's quite philosophical and if you like the talk today you may like the book as well. So that's enough the presentation of myself. And now I'll show you, there are three parts of my presentation. First I'll show you the trends which I think exists right now in the market, in the world of software development. Then I'll show you the problem which we have and then I'll introduce the solution which I think can solve the problem. The trends. I see three trends basically which are related to the problem I'm gonna discuss later. First of all, in the area of DevOps and not only DevOps, we have the variety of tools and instruments and frameworks and everything and the variety grows. So we have more and more of them. There are some statistics that show that the market of DevOps tools is huge now but it's growing about 15% every year. So it means about one-third in two years. And when it grows, as far as I understand it, it means that many tools go out of the market and many tools show up. So it not just grows in the size, it also grows in the variety. We have more and more of them. I found, and it's not only applicable to DevOps and it's not only applicable to tools, there are also frameworks, languages, web services, instruments, all the different things. So we are growing and it's becoming more difficult to manage this whole landscape. I found this picture on the internet. It shows how many instruments we have for continuous integration, for data management, for operations, for logs, for different things. And this picture is changing every year in a lot. I also, I didn't find my tool in this picture, unfortunately, but you may want to check it out later. Again, like I said, it's a pretty simple chatbot which you can initiate in GitHub just in saying a few words to the bot in your ticket and the bots will reply to you and then what it can do for you and just on your simple command, it can take the configuration from the GitHub repository, put it into Docker container, build your project the way you want it and deploy it somewhere. So we use it very intensively in many open source projects of ours and commercial projects as well. So all you need to do is just inside your GitHub repository, configure how to package everything and where to deploy and then the tool, the router, will just start the Docker container, build everything inside and it's all free. That's the beauty of it. So it's for small projects mostly and for mostly for open source, so check it out. So the first, the trend number one is that we are growing in size in the variety. So we are growing in the number of tools we have on the market. The second trend is that the data volume grows. So we are having more and more data to process. We, I mean, we mean technical people, devops, engineers. Again, some statistics. This article says that over the last two years, 90% of data in the world was generated. I'm not sure this data is accurate, but it seems pretty, you know, pretty huge. So we are growing in the amount of data we need to process. That's obvious, but we have also trend number three, is that the turnover grows as well. So we are migrating from company to company, from project to project. We, technical people, the people who are responsible for that variety of tools and for the growing amount of data. Again, a few quotes, a few articles. This one says that, and I can restate it in my own words, that in the past it was considered a bad practice to change company frequently and often because that was a sign of disloyalty, or you call it that way, but now it's changed. Now, as the article says, if you don't change the company every two years, then you will get less money than you deserve. So now everybody understands that we need to change places. We need to come from, to go from one company to another. That's now part of the culture, this is part of the industry. And the last survey by Stack Overflow demonstrated that 35% of all the people who took part of the survey changed the job during the last year. And I want to validate the number. Can you raise your hand if you actually changed your job in the last calendar year? Well, it doesn't matter, you see we obviously can confirm the number. So it's maybe even more than 35% in the room. So we changed job voluntarily, or we were forced to do that. It doesn't really matter. What the point is that we move from company to company, and at the same time, the company has the growing problem of the many, many tools we have to manage and the growing amount of data, but people go from company to company. So we put this together, and this situation, I'm getting to the second part of the talk, this situation is just making the old problem even worse. And that old problem is that the problem which is called the bus factor or the problem of control of information, it's the problem where people are taking control of the information, taking control of the knowledge and don't want to give that knowledge to anybody else because they want to sit on that knowledge and control it. And this quote from a very popular book says that ineffective people do that. I would actually argue with the word ineffective here. I think effective people do that because they understand that the monopoly of information is only good for us, for technical people, and it's called job security. So we want to sit on that information. We don't want to give it to somebody else because that actually protects us in the place of the company. But at the same time, we change the place every year. So that makes the problem bigger for the company. And we turn, you know, we become, not we, but it's the term which there's information, this knowledge which we sit on, which we control is called silos of knowledge. Did you know this term before this presentation? You did, some of you. And let me ask you before we continue, do you really think that this is a problem that people actually sit on the information that they don't share it properly and that actually hurts the business? You do agree with me. Okay, that's great. So this silo of knowledge, as I found this article, it's scientific one, it says that the presence of this silo, it's not the technology problem, it's a cultural problem. And they call it, it can be a person, a department, an application, a database, a network, something which only a few or a small group or just one person can access, can have access to or know how to get access to. So it's not a problem of technology, it's a problem of our culture. And I'll give you a few real examples of what this silo of knowledge could be. First of all, it's the source code. It's obvious. If I know how the source code is written, how it works, if only I can maintain it, that's my area of control, that's my domain, and that's, I can only know how it works, it's not good. Second could be credentials. So if I have the credentials for the DevOps operations, if I know the passwords, if I know how to get access to the server, if I have the keys, then that's also some information which I control. Scripts, that's the core, I think the core element of any DevOps infrastructure. The scripts which deploy or release or package or do something, and if only I understand how they work, that's my silo of knowledge, and that's something which I want to control and don't give anybody else. Configuration files, how those servers are configured, how they are deployed, how they work, and all that stuff. And the data, of course, the data model, for example. If I know how my relational database is designed, if I know the relations between tables and I understand the logic behind them, then this is definitely the information I'm not gonna share or it's difficult to share. So it all hurts the maintainability. That's the word which summarizes the problem, the maintainability. So we are people, technical people, who control information and don't allow that knowledge to be spread over the organization and to be visible by everybody or to be understood by everybody. We are the threat to the project maintainability. So now I'm getting to the last part of the presentation, the solutions. I'll show you how we manage that in our organization and how the philosophical approach we have. And I think the solution is about the attitude, about, again, it's a cultural thing, it's not a technical thing. It's how we can change the mindset of people, how we can convince them that they have to think differently. That's the only way the problem can be solved. So most of us understand the problem like you just demonstrated. Most of us understand that we are the threat to maintainability, we are the problem. And now how to solve that, I think it's the matter of attitude. So in our company, we do change the mindset and we do it in three, I'll show you now three conceptual, conceptual, not philosophies, but principles, three principles which we enforce to our engineers. And they are quite extreme. So I'm not saying they will work on your projects but at least take something from them. Some of the principles may help you in your situations. Number one, no magic. We are trying to tell them, we're teaching them to stop thinking that what they do is art, to stop thinking that, to stop being proud of their irreplaceability. So traditionally, technical people, I'm also a developer, I'll show you my GitHub account. Traditionally, we think that what we do is some magic. This is some art, it involves a lot of creativity and if I can do that and nobody else can do the same, then I'm a great engineer. That's the attitude with which we're trying to change. We're trying to tell them that software development should be a manufacturing process, more a manufacturing process than art. Obviously, there is some art elements, some creativity parts of what we do but the majority of work we do has to be done like the normal traditional manufacturing process like car making, construction, any other manufacturing industries. And we're trying to tell them that in this quite famous phrase of the French philosopher of the 18th century, we just need to replace the word just. We are actually cogs in the machine. We don't need to be ashamed of that. We're telling our programmers that we need to think of ourselves as actually cogs in the machine but we are changing that machine every year like we already understood. We are changing, we are moving from one machine to another and in each machine we have to play the role of a good cog, the good element, the good part of that machine. And most of them don't like that in the beginning, of course, but we are trying to teach them that. And in this question between what's more important, people or the product, we are, what do you think actually? So what do you think is more important when we all get together in a team and then we are developing the product? So what do we need to pay more attention to? To the people who are in the team or the product we create? So what's more important? Having in mind that we're gonna go different ways in a year. I think it's obvious, the question that the product is more important because we are replaceable elements. We inevitably or voluntarily or somehow we're gonna go to another product. So people are less important than the product they create because people move and the product stays. And the good team, that's the philosophical point we're making, the good team makes a product which another team can understand. So the good team is not the team who can make the product, it's the team who can make the product another team can understand. That's the difference. So we need to value more what we create, not who we are, not how brilliant we are. It's the question of how understandable the product is for somebody else. So the maintainability is way more important than the brilliance of us. And that's again quite difficult to digest in the beginning. So that's a summary of the first point is that don't learn how it works, make sure it doesn't need to be learned. So people usually, technical people like myself, when we see something that is difficult to understand we're trying to learn how it works, we're trying to become experts, we're trying to move the knowledge, not move the learned knowledge but grow the knowledge inside our heads. When I'm getting the new tool, when I'm starting to work with the new framework, when I'm starting to solve some problem, I'm becoming smarter in that particular area. And then of course I am the bottleneck, I am the expert, I am the irreplaceable element of the product, I am the problem. So we are telling our programmers that when something is not clear, when something needs to be learned, when you feel and see that you need to get to accumulate some knowledge inside yourself before you can work with that. Don't do that, instead improve the product, make sure the product is understandable, make sure the product is so easy to understand that anybody can work with it, that anybody can start making changes in a few hours. And for example, I'll give you a practical example. Let's say you have a script which doesn't work for some reason, which supposed to deploy something and then you open the script, you don't understand how it works and it doesn't deploy. So what you can do, you can study the script, you can understand how it works, you can spend a day on learning the piece of code in front of you and then you will see, now I changed that line, you change that line and it starts to work. But if you see that situation, that one year of study, that one year of understanding what's in the script is a waste of your time. So instead you need to spend maybe three, maybe five days to make the script easier to understand so that anybody will be able to fix it in half an hour. So instead of making yourself smarter, make the script smarter. So the bottom line is that don't accumulate knowledge in yourself, make sure the knowledge which you may find in a project is in the digital artifacts. Point number two, that was the first one, no magic. The second one is no meetings. In our teams, we have technically, literally no meetings. So we don't meet, we don't talk, we don't have even chats, we don't have in Slack channels, we have nothing of that. All we have is GitHub tickets. So here's the problem, here's the discussion on GitHub, we talk, we close the ticket, we're gone. We have no place where technical people can communicate. And I'm telling you, there are about 100 people working right now in over 25 projects and we're doing it for years, for the last four years for sure, and we have zero meetings and zero, even online chats. That may sound a little bit extreme, but that's possible. So again, the question is, so what do you think is more important to talk and discuss the problem or to put the information into the artifacts? So obviously, even agile suggests face-to-face communications. We think that artifacts are more important. We think that if you have a need, if you feel that you need to talk, if you need to sit in the room and spend the next two hours discussing what's going on and making some technical decisions, there is a problem in your project. Everything should be in digital artifacts. It's not easy, it's way more, it's way easier to just talk and make a decision in the room than to make your digital artifacts understandable and clear and editable. So I'll demonstrate with a, I actually added this slide today and to even better illustrate. So if you compare the ancient civilizations which built beautiful things and we compare the software we create right now, the question is how they managed to achieve that success long time ago? I think not because they had like brilliant, talented individuals who knew how to do that, not because they were so smart, you know, some individual, some people, particular people who knew how to do that, not because they had talented artists. I'm speaking about like the whole timeframe of the entire civilization. I think they made it possible because they invented books. So they invented the mechanism of transferring knowledge from one generation to another, from one group of people to another group of people. That's how knowledge grows. If they would be only talking to each other, if they would only having meetings in their rooms, then they would not be able to build as much as they build. The same for us. But in our case, generations are way shorter. They're just one year, as we already agreed. So we have a generation of programmers staying in the project for a year and then they quit. And a new generation comes in. And that new generation is supposed to inherit the knowledge from the previous generation. Just like those guys inherited the knowledge from their previous generation. If we don't put the knowledge into digital artifacts, if we don't write books, so to speak, if we don't make our code closer to books, not something cryptic, which only the previous generation was able to understand, but something which the next generation will be easier, will be able to pick it up and continue, then we cannot build anything if we don't do that. But if we have those books, then we can be as successful as ancient civilizations. So the summary of the second point is that good programmers know how to explain. The best programmers know how to write. So that's what we're teaching our programmers. So if you don't know how to express your thoughts and writing, if you cannot convert your ideas into documents, into UML diagrams, into source code, into scripts, which I can understand in a few hours instead of going the full path for months and learning what you had in mind, then you're not a good programmer. So best programmers, they know how to write. And that's actually what we see most people are actually lacking when they join our teams. Most programmers are used to have those meetings inside the room and they cannot actually write. And point number three, which is the most provocative, no salaries, that means that in our teams, we are, because we expect people to, we expect people to always share their knowledge. We expect them not to become, not to become those silos of knowledge, exactly. We expect them not to be like that. So we expect them always to give whatever they know to bring back into digital form to the project, then we have to pay them for that. We cannot pay them any more for months. We cannot pay them for a week. We need to pay them for what they bring. That will motivate them a lot to actually give us the knowledge as soon as they can, and then they will do whatever they want in their free time. So if you ask me at that point, what's more important to value your people and value your team by the time they spend in the project or by the results they actually bring, then obviously if you want your people to not hold the knowledge, not to become the silos of knowledge, not to become the bottleneck, then you have to value them somehow by the results. Maybe not as extreme as in our case, we have no salaries at all, we only pay for results. Maybe in your situations, you may value them somehow by some points, maybe some bonuses, but what's important is that every time some results gets into the repository, the person, the author, has to be rewarded somehow. So that's the most hurtful points, so I'll just skip to the next one. And that's the summary, so that's my one of the last slides. So we had in the past, we had knowledge accumulating experts, which are the problem. And now we have expertise providers who don't accumulate anything, they provide the expertise. The person joins the project, we didn't know something, that's the knowledge coming in, we got the knowledge, bye-bye. So we expect initially that the person will quit and we don't want that person to stay, we want the knowledge to come from our people, from us, to digital artifacts. That's how we prevent problems. So here's the summary, the best engineers are the easiest to replace. So if you are, if it's difficult to replace you in the project, then most probably you're not the best engineer. If it's easier to replace, if you're sort of invisible, if the company does not depend on you technically, then you're a good engineer. And here's what you do after the talk, so first of all you can buy my book, it's called Code Ahead. Second point, you can try our company if you have a project and you want to see how our teams work and you can, if you want a few people from our team to work on your problem and see how actually that happens with no meetings, no paying for the time, and no magic, then try that link. And you can follow me on Twitter, LinkedIn, Facebook, everywhere. And that's it, thank you very much. So you were talking about, you want the information in the digital artifact, you were talking about books, I think was what you were saying. But I'm a little bit skeptical about independent documentation from code. I want the code to be readable and understandable on itself. I don't want a separate document, but I don't, I don't know how you meant that distinction. Was it just the way you're saying it or you really think separated documentation is very valuable? It occurs a lot to me as write once, read never. That's a good question, yeah. Well, actually I've never said the word, or did I say the word documentation? But anyway, I'm a programmer myself and when I open the code, the documentation is the last place I'm gonna look at. So first of all, I want to look at the code. First of all, I want to look, well, documentation, I mean the documentation, I mean some manuals where you need to read how these things work. When I look at, I look at examples. I look at the API and that's how I understand the code. So the last part is the last thing which I would see, I would like to see is documentation. But that depends on the situation in the project, depends on the culture in the project. So from team to team. Yeah, so my suggestion is to use documentation like manuals, actually books as a last resort. Of course, the first, the easiest way to understand the code is to actual examples, maybe test cases, maybe some API and then the source code itself. And then documentation. While you bring the microphone, yeah, so it's always the question of how fast you can understand the problem. You understand the code or the product. Test cases. Yeah, of course, definitely, yeah. Hi, you said you treat the majority of the development process as something analogous to a manufacturing process. What parts, if any, would you not treat like a manufacturing process? Well, that's a good question. Of course, not everything could be treated as manufacturing. Of course, we need some art and creativity. Usually, in our cases, the start of the project is more creative, needs more creativity than the rest of the life cycle. So initially, there are just a few people there, not the big team, there's just one architect and maybe two people, and they create the architecture. They make the key architectural decision. At that point, it's not really manufacturing, it's more artistic, because you never know what's gonna come out of that. We're gonna use the no relational database or relational database. That's the question which costs a million of dollars later. So you need to make the right decision and you need the brilliant person to do that. Like with the ancient buildings, that's the same. So first, you need to, you need an aha moment. You need to decide that's the way it's gonna look. And then you have the manufacturing. So initially, the second part is the UI. I think also UI people, UX people, it's difficult to turn them into, to cog in the machine, because they also make some decisions which I don't know how they make them. So that's also, we try to treat that process as manufacturing or we fail. So we failed in the architecture and we decided don't touch the architects, let them be creative and then don't touch the UI people, let them be creative. The rest is fully, it could be completely disciplined and routine process. Like DevOps, like mad programming, writing code. Hi, thank you for your interesting talk. You said that your engineers do not talk, you expect them to live within a year and you don't pay salaries. What makes you think you get the best engineers out there? Well, actually that was our fear when we started that, like five years ago, to experiment like that. And we also thought that, we thought that only junior people will work with us because they need some money to buy some food. But, or maybe that's the description of a senior engineer. But eventually we found out that junior people do not stay with us. They don't like that model. But senior developers actually enjoy it a lot and they appreciate that attitude. Because they always know that the scope of work for them is very closely defined. They know that there is no pressure for them. They know that they always provide the best expertise they can and they can leave at any moment of time. So they work with us more like free craftsmen than, you know, I don't like this word, but like slaves, you know, sitting in the office and working because they are told to do so. So we work with people who are more free to come and go or who actually valued not with the salary, but for the things they provide. So you know how this, to fix that, you fix that, we appreciate that. You don't know, we'll find somebody else. Which is a traditional model is more like, you stay with us for a month, you know how to fix that, you don't know how to fix that, you still stay with us. That's more, you know, that's the model which in my experience is less appreciated by junior, by senior developers. All right. Just experience. Yeah. All right. Thanks guys. Thank you.