Video details

Stop Punching Yourself in the Face - Hannes Lowette - NDC Oslo 2021

Career
02.20.2022
English

We developers have the tendency to punch ourselves in the face. We do so by making choices about the software we build: architecture, frameworks, libraries, cloud providers, etc. If you’ve been around for a while, you have probably felt the pain of at least a few of those choices.
And yet, if we apply simple logic, we might know in advance what might work, and what will hurt us. Want to hear more? Come to this session to learn how to make choices responsibly, with the goal of minimizing the chance that you will regret them later on.
If only there was a certification that would prove to your peers and superiors that you are good at making these choices... Well, there is! RAD Certification! I'll end my talk by telling you how to get your RAD certificate and the corresponding swag!
Check out more of our featured speakers and talks at https://ndcconferences.com/ https://ndcoslo.com/

Transcript

Hi, I'm Hannas, and today I'm going to talk to you about how you can stop punching yourself in the face, which is, like, my favorite activity, not punching myself in the face. Now, the reason I made this talk is I've been in software teams for over a decade and a half, and I've seen teams hurt themselves over and over and over again in the same way. And it became a pet peeve for me. And I figured, like, I'll have to tell the story to people. So the first thing that I want to look at is, what are we meant to do as software developers? When we deliver a software product, we're actually delivering value. We're helping a business succeed. One of the things I always do, I'm a consultant, is I try and follow the money. It's like, how is this company making money? Where is the value? Where is our software product going to make a change and help this company succeed? And if we try to keep our eyes on the price and we try to keep that into the back of our heads, a lot of this will come naturally. And for those who were in my talk yesterday, they know that I have a thing with Magpies. Now, let me tell you about the Magpie. Gonna tell you about two creatures. The Magpie is a bird. It's black and white. It has a pretty long tail. It grows up to about half a meter long, and it has a wing span of up to 60 CM. Their own divorce. They're pretty intelligent, and they're rumored to be attracted to shiny things, right? You've all heard this myth, right? The bird that steals the jewelry. Now, the second creature that I want to talk about is the software developer. You should all be familiar with that creature. Very human. They might be black, might be white, and they don't have a tail. They grew up to about 2 meters, 20. They don't have wings, but they're also omnivores. They're also pretty intelligent, and they're also attracted to shiny things. In this case, they're attracted to libraries and frameworks and architecture. But it's always like, oh, shiny. I want that. Now we have to wonder ourselves. Is that so strange? Is it so strange that us software software developers are attracted to all those shiny things? I don't think it is. I mean, software development is still a very, very young profession, unlike woodworking, which I do as a hobby. In woodworking, they found out a long time ago how to use a chisel without splitting the wood. They found out a lot of techniques that have been used for decades, if not centuries, and they are like a guaranteed way to success. But because our profession is so young, relatively, we are still finding out which the surefire ways to success are. And actually, there are none. And because of that, everything is changing. Libraries that are relevant today might not be in two or three or five years. If you're in the JavaScript world, they might not be relevant tomorrow. But still, knowing all this, you got into this profession regardless of this knowledge, like I'm going to have to figure stuff out on my own. That sounds like a cool job. So is it weird that you're attracted to all these shiny libraries? No, I don't think so. Second problem is our education and I like to compare the state of it educations like software engineering to building houses. And if you go to College, what you would get by comparison is you would get a course in brickling. They'll teach you how to build a wall and your practice to build like two meter wide walls. That's the thing you're going to learn. And then we're going to teach you a class in tiling kitchen walls. So you do some tiling and there will be a theoretical course maybe about roof construction, like how can we do the beams for a roof so that it doesn't collapse? Of course you'll get a course in electrical wiring and they'll teach you how to do some pipes, right? And this is the knowledge that they send you off into the field with. But instead of asking you to do any of these things, what they tell you to is can you like design and build an entire house? Because that's the job that they usually store upon us as software developers. They ask us to do the whole job end to end, do the architecture, build it, deploy it, run it, everything. But those are the only skills you got. So we need to look for guidance and we do. What everyone would do is we look at people who are successful. So we come to conferences like this one and you listen to people like me and we tell you what to do, right? And that's pretty cool. You'll also go on the Internet and you'll read some blog posts or you'll look at some videos or you'll try and gather knowledge and the natural thing is to look at the big companies that are succeeding. It's like how are they doing it? How are they getting to the end in their software delivery? And we look at all these things and we do as these do. And I have some rare footage of a software developer that tried to implement Kubernetes in his company and he ran into the wall. And I'm sure that a lot of you have felt this feeling that at some point during your career you run into a wall and you wonder why, why did you run into that wall? What happened? What did we do wrong? And for that you're going to have to join me on a journey with Chat. I Googled asshole Chat. I got this GIF. Any resemblance between Chat and any person that you know or that I might know is merely coincidental. Okay, these are not true stories. So I have six stories and then I'll wrap things up. And the first one is about RavenDB. Now, I was in a team with Chad and we had this application, this application processed text files. The text files came in through an API and they needed to get processed. And what our product already did. It extracted about 70% of the data that we needed from those text files. And it dumped that into a database for the online system. But at some point, the product manager comes to us and he says, yeah, I think the other 30% might be valuable in the future. So is there a way that we can maybe store those text files for later usage so that if we ever decide that we want to do something with those 30% extra data, we can actually get it? So up comes chat and you have to know, Chad is one of these guys. He reads all the blog posts, he goes to the conferences and he's like, oh, I've learned about this great new technology. It's called RavenDB. It's a document database. It's really fast. And what we can do is we can actually parse those text files and dump them into RavenDB so that in the future, if we need to query the data, we can just get it. So, yeah, that's what Chad did. Now, the problem is he started doing this and he set up a VM, he installed RavenDB on it. He built the whole system like parsing the textiles, dumping it into Ravend DB. It took him quite a bit of time. But what we learned really quickly is that the price per gigabyte of something like RavenDB is extremely high. You have licensing costs, you have to maintain your operating system, you have to maintain the database engine. I mean, it adds up. And because of all the moving parts and it was the first time that he actually did anything real with RavenDB. It took a lot of time as well. And the biggest problem was whenever the structure of our text files changed, his system broke because it was actually parsing the contents and putting it into documents. So what Chad forgot here is to check if this technology was a technical fit to his problem. Is it suitable to solve the problem that we are having? So the questions that you should ask yourself, are these like, are we not trying to put the square block in the round hole? Are we not trying to use this technology to add it to our CV? Is it actually solving a problem that we're having right now? And you might want to compare it to other competing technologies to see if you can find a better fit. You will have to wonder, like, is this going to help us or is it going to cost extra time? What are the costs that are implied with this solution? And what are the extra maintenance costs? Because that's something, as developers tend to forget. We look at the shiny, we get the thing up and running, but all the costs that will come down with it down the line, we forget about those, right? That's not our problem. Well, it usually becomes our problem. So where did Chad go wrong here is he forgot to consider that Raven DB is actually a database. And a database is meant to be queries. And RavenDB is very powerful. It has indexing, it has projected views. It's a very powerful thing to use, but if you only use it to store stuff, it's going to be extremely expensive. So what could he have done is use something else where he didn't have to parse the text files and where he could just dump them into something where he could retrieve them for later use. Something like Amazon S Three or Azure Blob Storage. That would be perfect fits for this scenario. You dump your text files in there, done. You don't need to parse them. Price per gigabyte is extremely low if you want to have your data globally redundant. I mean, it doesn't really add that much to the cost and you don't have to maintain it. Amazon or Microsoft will do that for you. So that day we learn. Well, in that project, Chad and I, we learned about technical fit, so we took that into our careers. For the next story, I was working with Chat and we were brought in to a customer and they had an ASP. Net MVC web application. It was in the MVC four times. It might have been MVC five, but like, still full framework. And a lot of this application had been written by nearshore contractors. I'm not going to name the country. And they brought us in because performance was horrible. So we started looking at what was actually happening in the code base and we were profiling this. By the way, this was 2014. This becomes relevant to the story in a minute. And basically what we saw there is that the objects that were selected through the RN, they lived all the way until the presentation logic, which meant that if they were building their menu, for instance, they were not just triggering an N plus one select, it was like an N times M plus one select. It was like horrible menu loaded 2000 queries to the database. No wonder it was slow. Right? So we figured that the easiest path forward is if we cut like somewhere in the middle. Let's shield the business logic from the presentation part and make sure that that is a hard boundary where we cannot have this kind of shenanigans again. So that's what we set out to do. And Chad had an idea. He had worked with Agata on a previous project. And for those of you who don't know Agata, it is basically a request response library on top of WCF. Yeah, I'm that old. Sorry. So we started to check if this would actually help, and it would solve our issue because it was a boundary inside the whole process of retrieving data from the database. But the cool thing is that we could either run it in process, which didn't cause any overhead for us at the time. We could still keep the same deployments, but if we wanted to, we could actually move it to work over WCF, over the network, and then separate it into two different servers, which was attractive. It's like it's a good plan to have for the future, but we don't have to invest right now. So that was good. So it's definitely a technical fit for the problem that we were having. Can you guess what went wrong? Any of you know, Akata, by the way? No. Okay, what went wrong is this. Chad had forgotten to check on Kid hub and ICATA was mainly maintained by one person, David Ryan. And at some point around 2013, remember, we did our project 2014. David lost interest in Agata or disappeared off the face of the Earth. I don't know what happened, but basically this library was no longer maintained. But this was also the time that a sync await became really big in the Net world. That was like the time that that was starting to happen, but right out of the box, after we had implemented a CATA in our code base and we wanted to switch to a new version of the framework where we could actually use a single weight, we found out like, oh my God, that doesn't have support for a single weight. So instead of having something that really helped us, the thing that we put into our code base became a liability because it wasn't being maintained, which meant that we either had to fork it and maintain it ourselves or switch to something else and invest the same effort all over again. And that's no fun. So what the Chad forgets is he forgot to check for a warning. Science warning. Science is can this technology become a risk for us? And of course, we don't have a Crystal ball to look into the future, but there is some stuff that you can check. It's like, who maintains this project? Are they still actively working on this? Are they still blogging about it? Because if they're no longer blogging about it and they're blogging about other stuff, it means that they might lose interest and they might be working on something else. Is the source code available? How is it licensed? I mean, if it's something really critical to the thing that you're doing, you might want to maintain it yourself, but at least you would have to be able to. So the licensing model should allow you to make a fork and maintain it yourself, and you should be able to get the source. And when companies get bought by other companies, that's also usually a moment that licensing models change, and that's a huge risk now what Chad could have done is used Mediator, because Mediator does basically the same thing as Agata, but it was actively maintained by more than one person. It's mainly Jimmy who does it, but it's still something that could have given us all the benefits of Agatha without the risk of using something that wasn't actively maintained anymore. It was also open source under the Apache license. So if Jimmy were to die, we could actually take a road forward and use that. So when you know about technical fit and you're checking for warning signs, not much else can go wrong, right? Well, you know that there are four more stories coming. So you know what the answer to that is? On one of the next projects that I was on with Chats, we were faced with a situation like this. It was basically mostly a credit application built on a proper solid dependency injection stack. I think this was probably around 2016. It was built using ASP. Net, MVC use SQL Server. There was a Bus architecture that allowed our software product to talk to other products inside the company, and actually it was pretty well built. Developers were not struggling to deliver features. It was okay. And then the task came. It's like, okay, we want to have a screen where you can edit some data. But what we basically also want to see is the entire audit trail. Who edited the data, who did what to it, what is going to happen? And it was just one screen. But Chad, like being a responsible developer, said, okay, but I have a solution that is like great technical fit, and that is also that doesn't have any warning signs. It's very actively maintained. So he came up with Event Store. Chad had become a really big fan of Greg Young around that time and about all the Cqrf stuff that he was speaking about. And inevitably he came into contact with EventStore and it's perfect. I mean, if you want to project an audit trail and show it in a screen, Event Store is something that can really help you with that. And it was being actively maintained. So technical fit, warning signs all good. So what went wrong? Well, Chad started implementing this and he built that screen and he used the fence Store and it all went really well. But let me tell you about the team that we were in. We had some remote contractors in another country and there were quite a bit of juniors in the team and none of them had events to our knowledge. But Chad worked on that feature on his own and he delivered it and it was glorious. I mean, it worked really well and he used EventStore in the proper way. What he forgot was to teach the others about it and the result was that none of them actually touched any of the events or stuff. So if anything needed to happen in an event, store screen. The only guy who was doing it was Chad. So when Chad was the only one working on that, that became a bottleneck. If Chad was absent when he went on holiday, that was like a period that we could not deliver anything on the event store screens, which is sad, and it became a risk and it became a problem. We eventually got the whole team on board. But team skills are not optional. I'm not saying that you have to teach everyone, but at least you have to be able to deliver. Because if you give the business this nice screen where they can see the audit trail, you can be sure that if they're demanding new features, this is something they're going to want everywhere. Right? So you'll build more and more and more screens just like that. And building skills takes time. I mean, nobody flips a baseball bat like that without, like, hours and hours and hours of practice. So when you bring something new on board in your team, you have to wonder, how much is it going to cost to get everybody up to speed on this? Do we already have the knowledge? Good. If we don't like how do we build it? Is the knowledge available? Is there documentation? Do we have to write our own documentation? Do we have to write the code together? I don't know. Figure out what you need and how much it is going to cost to build that knowledge inside your team so that this technology will not become a bottleneck in the future. There's a couple of really good ways of doing this. I find pair programming or mob programming an excellent way to spread knowledge. If you build something together, not only are you building the thing with more than one person, usually of higher quality, you're also spreading the knowledge. Everybody's knowledge goes into the same thing, and that is a glorious way to do it. But there's also other things. You can go and follow a course somewhere. You can look up videos online, you can build your own documentation, and you can help people with their first steps when they're using this new thing that you're trying to bring on board. So when the team is up to speed and we're choosing the right technologies, our life becomes already a lot easier. But then something else happens. Same project. But Chad comes to me one day in the morning before all the others arrive, and he says, Hans, we need to talk. We need to stop using entity framework. For those who are not in the Net world, the entity framework is our Orm of choice. It maps between objects and the database. Okay, I'm intrigued because, as I said earlier, the application was mainly crud, and RM is a perfect fit for those kinds of applications. Why? So I asked him, what are your frustrations? Why are you telling me that we shouldn't be using entity framework anymore? It tells me it's very slow and it does so many different things and we're only using it to query and to update data. I mean, we don't need all of this. We have no control over the SQL that it outputs. And the sequel looks very messy. I mean, the screenshot on the right is an actual screenshot of, to be fair, of an older version of Entity Framework. And all of these arguments are true in the correct context. But while this SQL actually looks messy, SQL Server doesn't really have a problem with it. It's properly written. It's not like it's really slow SQL. It just doesn't look easy on the eyes for us as developers. So I'm wondering what's happening here? Why does he want to move away from this? So I sat down. Can you show me some of the problems that you have and the things that were actually going on there with Chad is first of all, he was hitting a lot of DB context initialization problems. For those of you who have worked with Entity Framework, they will know the first time you create a database context of a certain time, entity Framework needs to build its mental model. It needs to learn about what do the tables look like in the database, what do the classes look like in code, and how do I map between those? In the old days, that used to be all in a huge XML file that caused like countless merge problems. It was the. Edmx file who did edmx at some point. Yeah, no fun, isn't it? But even if you use code first, any framework needs to build its mental model and that takes time. And from the second DB context that you make at the same time, it's actually snap fast. But why does it felt so slow for chat is when he was coding, he was running from his IDE, which meant he restarted the process every time and he would hit that DB context initialization every time. And his conclusion would be like, oh, this is very slow. Look, I did my first request, took 600 milliseconds. That's not acceptable. Did the same request again, 33 milliseconds. Yeah. So once I explained this and I was like, oh, okay, but there's other problems. I mean, look at this one. This one is slow consistently. And what was happening there was he had written an M plus one select, n plus one select are where you Select N records and then inevitably by accident trigger an extra query for each record that you're looping over. It was usually at those times, lazy Loading was the default. So if you forgot to fetch the dependent entity and you accessed it, Entity Framework would be a nice guy and fetch it for you. But it meant a lot of round trips to the database. So if your API call goes to the database couple of hundred, maybe a couple of thousand times, there's no way you're going to get, like, sub 100 milliseconds performance. So we looked at that by opening a profile, it's like, what's actually happening here? Oh, you're triggering lots of queries. So if you just include that entity and Eager loaded on your first fetch, that actually solves it. And suddenly the API call comes fast. And then there was one missing database index on a large table. I mean, that's not an entity framework problem, but it's something that the profiler and the SQL Server performance Analyzer will actually help you with. So we put an index on that field, and it actually helped the query immensely. And then there was the last thing. There was one place where he was actually fetching the entire entity and he only needed a couple of fields. Now it was an entity that had 200 columns. Don't ask me how we got there, but by writing a projection, we didn't fetch all the huge because there were a couple of block fields in there. We didn't fetch all the things, we just fetched the fields that we need. And also that became fast. And after I sat down with Chad and we talked about these things, it became clear to me, like, until that day for Chat, entity framework had been magic. And what I always encouraged developers to do. I coach a lot of young developers fresh out of College at the company that I work for. I always tell them to take away the magic, try to understand how the thing that you're using was built, because if you do that as it worked for Chat. Actually, after we sat down and looked at all those problems, Chat became like the go to guy in the team on entity framework. He became a big fan. But when you take away the magic, it becomes a lot less likely that you're going to abuse the technology and use it in the wrong way. I'm not saying that you have to build your own. Don't do that. For most of the things that we do, there's people smarter than us who have already done it for us. So don't do that. But try to understand what they had to use to actually build this technology that you're going to use. Try and maybe write one of the features or try and look at the source. Do you understand how this thing was constructed? And if you do that, it becomes a lot easier to derive the proper way of using a certain technology. If it's no longer magic to you, you're going to do a good job using it. So at this point, we feel really skilled and we move on to a new customer, and we arrive at a team and Chad does this amazing job. It was a huge code base. It had been going on for eight years. And the Chat that I worked with on that project, he was a hero. I mean, he was the superhero of the team. He was the lead developer and the whole team really admired his skill. He was basically the only one that spent his free time learning new stuff, but he always brought it back to the others and he really liked doing things the right way. And he took care of the team skills part when he learned something new, a new framework, an awesome library. I don't know. He explained it to them. He gave a presentation about what is this technology? How does it work? How was it built? What are the tips and tricks when you're using it? He built on our confluence. He built a documentation page about the Do's and Don'ts, and he got everybody on board. And when Chad did that, the whole team looked up and was like, okay, yes, that is a better way of doing things. Let's do it like that from now on. And they would do that. But what went wrong in this project because even though he took care of technical fit and he checked for warning signs and he got everybody up to speed and he took away the magic for everyone, it still went wrong. Otherwise I wouldn't be telling you the story right. The problem was that all of the old code remains written in the old way. So we had a code base where you could basically date features by looking at what practices and technologies were used. It was like, oh, this front end is using Angular, not Angular JS, and it is doing dependency injection in the background. It's using that version of this. And that must have been written around 2017, probably spring 2017, right? That was the code base that we had. It's like age rings in a tree trunk. You could date it. And that became a huge problem because after those eight years and Chad doing this great job the whole time, we have four different ways of doing front end code and three different ways of doing back end code. We have two API frameworks, we have two database engines, and we have three different ways of structuring the code. What I'm trying to say is if you do that, it becomes extremely hard to onboard new people on your team. Training a new developer on that team typically took three to five months, depending on the skill of the developer. But three to five months is a very long time for somebody to be productive because if you have a little bit of turnover on your team, that means that your existing team members are also spending time for those three to five months on training the new person. So what you have to worry about is like, if we bring in new stuff, we have to maybe think about what we can throw away. What problem are we trying to solve with this new technology? And do we really need to bring it in? Maybe do we have an old thing that is similar that we can throw out now that would be really good. And how much effort would it be to actually throw that out? Because that is the hard part. You're going to have to explain to the business that you're going to invest a lot of time in code that you already had and that already worked. And to the business that feels like throwing away money. But it's the only way that you can actually keep moving forward at a consistent pace with a team for an extended period of time. So spending that money or that time is not optional. So make it very clear to them what the cost is of keeping both, like keeping the old code as it is and the new code that you're writing with the new thing. It's like we're going to have this new functionality on the new features, but the cost is that we have to maintain it. Every new developer that we train, it's going to cost us two weeks extra all of this stuff. You have to make sure that is clear to them so that it doesn't become a choice. So that it's. The only way of doing things is if we bring in something new, replace something old. What I would want to see is that you all build hollow trunks like this one, take away the old code and migrate it to the new way of doing things. And for instance, if you look at front end frameworks and you switch from one to the other, it's not really that bad if there is like a transfer period where you're doing both, but don't bring in a third before you finished migrating from the first, right? So estimate all of that. And then there's the worst thing that we developers do to hurt ourselves like really badly. The case that we were on was a Greenfield project. And as every developer stream like, oh, we finally get to do the chance to do things right. We can pick the proper technologies, we can do the right thing. And it was a small line of business application, wasn't really that complex. So we figured, yeah, we can try the new stuff here. The team was one senior developer and three Deafs that had some skills. They had a little bit of experience, but none of them more than three years. And what is really relevant is the team didn't really have any experience in running their own shit in production. All they did before this was just code and deliver it to the obstacle. But because they got the chance to do things right and the business was on board, the stack that they picked was they chose to do an angular front end, they chose to do identity server for their authentication and authorization, they chose to do Docker and Kubernetes. You remember the guy jumping into the wall, right? They were going to do everything microservices, they were going to use a document database in the back end and all of this was new. I mean, that by itself is a massive team skills violation, right? So the team got stuck. They really got stuck on learning the new stack and they really got stuck on handling, deploying stuff to production and actually delivering anything. But a lot of things became harder because all these things were separate services. They struggled with monitoring, with logging, with debugging. They struggled with the proper use of MongoDB because they had been used to having relational databases where all of the data could be queried in different patterns. And that was suddenly you had to think about how you were going to query it upfront when you construct your documents. That project got a huge delay because of that team skills violation. But there's something else that happened there. It was also massively over engineered for what it was supposed to do. So team skills. My opinion on that is when you bring in new stuff, do it one at a time, and if possible, if possible at all, try to avoid the pressure to deliver functionality with the pressure of learning something else, something new. Because if you combine those two, they will both affect each other. The time that you spend on learning is going to affect your ability to deliver. So when you learn something new, I'm not saying that you shouldn't, but budget the time for it, do it properly, do them one at a time, and explain this risk to your business owner. I've heard people say things like this a lot of times and it always turned out to be a lie. It's like when we do this new thing, we are going to be able to deliver it so much faster and so much better. Yeah, right after you've learned it. True, but not now. But the thing that really went wrong there is they took an architecture that would have been suitable if you have the problem set of maybe Netflix, but it was a small internally used line of business application. And the architecture, you could write that application that way. But the architecture really didn't help them. It got in their way. And this is something we do too often. We look at those big companies, we look at how they are successful, and we think that their solutions will also apply to us. But we forget that they developed their way of working just because they had a whole bunch of issues along the way. And if you go back and you look at Netflix's first presentations about doing microservices, you actually can find some talks where people are really honest about this. It's like, yes, we have this to solve that problem, but now we have a whole bunch of new problems. So we had to build tooling for that. And maybe a lot of that tooling has been commoditized over the last couple of years. But if you want to do proper micro services, you're going to bring in a lot of different things. If you want to be able to properly trace things, authenticate people in your system throughout the service. If you want to look at how stuff goes wrong and how to debug it and how to set it up on your local development machine, I mean, it's not trivial. I've heard people throw around the number. This was a couple of years ago that you would need a team for nine months and probably around a million euros before you would actually be able to deliver any features. If you were doing proper micro services now, because a lot of the stuff has been commoditized since then, we can maybe half the number. It's not magically going to be €50,000. It's going to cost you a lot of time and money to get up to speed. So what we should learn from that flakes is not their solution. We should learn about their process of how they got to this point. And when they started out, they didn't have a complex architecture, they started with something simple and keep it as simple as you can. Start with the simplest thing that you can start with. If we would have done that Greenfield application, just built a simple monolith, maybe learned Angular or MongoDB like pick one new thing, right? We probably would have delivered it semi on time, but what we would have done is we would have applied a lot of our skills, pushed it out to production, actually delivered value. And the most valuable thing is if you push something out, you'll learn how your users are going to use it. Because that's also something that we as software developers tend to do. We over engineer it's how our mind works. We try and foresee problems that we might have in the future. A typical one is scaling. We always think that the product is going to be way bigger than it actually is, right? So we already do stuff to make sure that we will be able to deal with it when it comes to that point. Except usually it turns out that it's another component than the one that we foresaw that actually needs scaling. So you optimize it for the wrong thing and when you push it out with a simple solution and you learn about it. I'm a huge fan of Instrumenting. Everything we push out, not just like logging and monitoring and which API calls are being used, like which buttons are users actually pressing? I've heard a talk once about a company where their idea for a new feature would always result in them putting a button in the UI that didn't do anything. It's like, let's see if users actually press this and they would log that and it went gracefully. When the user pressed it, it would pop up a message like oh, I'm sorry, this feature is not available, but they would know. And the button that got pressed a lot, it's like, oh, this is the next thing that we're going to build. I really love that approach. I mean, you're building what people actually want, but you can do the same thing with your architecture. You push it out and you see what is being used. Just have enough of a design to be able to deliver value, and then iterate on that design. I'm not saying don't do any architecture. I mean, architecture is important, and it has to support your ability to deliver value to the business. But you should just have enough to move forward. And then you learn and you iterate. So micro services is a very popular one. And I see so many teams doing micro services because they feel that it is a proper way of doing things. And there's this image from Martin Fowler, and you see, like, I'm standing way below the line. There the micro services. There's a couple of real reasons why you would need them. The first is scaling. If you need to scale certain parts of your software product. And I'm not even saying that it's only scaling the production performance. It can also be about scaling teams at different rates. Right. But if you need to scale different parts of your software in certain ways and you have to do it differently, then having separate services is a huge benefit. It's a balance of cost versus speed versus delivery. When you build a software product that needs to support multiple clients, where all the clients have different features and you can disable them and maybe replace them, that is also a very good technical reason to have different services. If different parts of your solution require different technology stacks, that's also a very good reason to have different services. And if you have conflicted dependencies in your product, where part A requires version X and another part requires version Y, that usually doesn't fly in the same process with most programming languages. So that's also a very good reason. All this we need to scale in the future stuff. I mean, that's something future you can solve that today's view doesn't have to solve that problem. So if Chat would have done the simple thing, maybe learned Angular, but didn't do Microservice, I'm pretty sure that he would have pushed out that project on time. And you can already prepare your code for splitting off services. Basically, you can already provide the dotted line like cut here, cut out this part in the future if you need to scale it independently. I have a whole talk about building plugins and doing that in process as a way of keeping vertical slices inside your inside your code base. But you still deploy it as one monolith, which makes it a lot easier to manage in a whole bunch of ways. So that's probably what Chad should have done, and he would have been able to deliver that value that we are so after. So that's the end of the six stories. I want you to remember the six conclusions. First, check if the thing that you're going to use is a technical fit to the problem that you're going to solve, is it going to help you? And then check if it's something that becomes a risk. At short term, there's a whole bunch of things that you can check if packages are critical for your software system. It's okay to read the blog posts of the person who are actually building this. You're actually doing your job. Then get enough people on board to be able to use this and to not become a risk and a bottleneck on one person. And make sure that none of it is matching to you. Take away the matching. Make sure that you know how it was built so that you use it properly. Take out the old stuff. Make sure that you're able to onboard people. Make sure that people can reason about the code base. It's very important and let your architecture solve your problems and not be the cause of it. It should not be the cause of your misery. It should actually be a solution to something that you actually ran into. And after telling you all this, you're probably wondering, like, who was this chat guy, right? Who are we blaming here? And in some of these stories, Chad was me, or it was the whole team or somebody else on the team that I was on. Or I totally made him up to drive home the story. But you might have noticed that I've written chat in all caps on all the slides. It's because actually, it's an acronym. It's a carelessly or helplessly acting developer. And in none of these stories, Chad did edit anything wrong on purpose. He was always acting with the best interests of the team at heart. He was trying to help, but because he didn't really know how to do it in the correct way, he ended up shooting in his own foot. So we have to wonder, if we don't want to be chat, what do we want to be? Wouldn't it be better to be read right? Not rapid application development. No responsibly acting developers. Well, today you can. If you're on board with my mission, you can help me spread the word about this. So you can follow Rad certification on Twitter. I made a certification program where you can become a certified rat developer. Okay, you can follow us on Twitter, or you can go on Ratset.com and take a quiz. It's ten questions. And after you've seen today's talk, it should be trivial and you can become rat certified. And I have these certification kits. Unfortunately, they didn't make it with me from Belgium. But what I'll do is for the first 30 people who show me that they got certified today, I'll actually send you one of these certification kits in the mail. And if you have a target with your manager that you still have to get a certificate this year. This is a really easy way to do it and the year is only going to be like one more month so if that is in your targets like get it out of the way today. My name is Hannah. I am the head of learning and development at a company called access in Belgium. This is my Twitter handle and for those who were here yesterday my ICQ number I'm trying to make ICQ great again. I have three kids, I'm an amateur guitar builder and I'm a Lego enthusiast. We have ten more minutes for questions so I'll be happy to take any questions you might have. Okay you all want coffee I understand if you should have any questions throughout the day I'll be running around so come and talk to me. If you show me that you're certified fine I'll take your address and I'll send you a certification kit. Have a nice rest of your conference and have a great day. Oh, one more thing. One more thing. Can I maybe promote tonight's after party a bunch of us are going to do funny talks where we try to make developers laugh and then after that we will actually play some music tonight on stage here downstairs so make sure you don't miss it. It's going to be great fun. Bye. See you tonight bye.