 Quick note, you have the slides right there if you want to download them. And before we get started, I would like to ask you a couple of questions. Quick show of hands. How many of you have absolutely no clue what agile software development is about? Okay, good starter. Who in the room has a pretty good idea but don't really use it in their daily. Okay. And now who in the room would consider themselves as fully agile teams and like, okay, who are the others? All right. So introduction already on, but you have my email and Twitter handle, so get a handle. Feel free to reach out. This is a very packed and dense talk. I'm gonna be talking about a lot of topics and I won't be able to go into details on many of them. So feel free to reach out. I'll be also around if you wanna talk a little bit more about some of those topics after the fact. Okay. Let's give a little bit of context. Why are we talking about this? One example that I like to use as an introduction is the airline industry. So it's a very fascinating industry. They create those very, very complex machines, you know, airplanes, pretty crazy. And they're able to ship them. Those planes are gonna be flying for 10,000, like millions of miles, hours, et cetera. Very low problems, crazy quality, really reliable. So we can ask ourselves, how do they achieve that? Really BQA process during the building and design and heavy reliance on checklists for process. And we'll be talking a little bit more about that later. Second example that, oh, sorry. Let me backtrack it for a second. So whenever Boeing or Airbus builds a new plane, you know, they put it on a tarmac, takes off. How many times do you hear about a plane, you know, taking off and crashing immediately day one? Never, right? That never happens. Now, how many times do you hear of a website being built day one? Right? So maybe we have things to learn from them. Another example that I like to use is construction business. Okay, you just spend fair amount of money building your dream house, okay? You're gonna expect that house to be, you know, pretty solid, first windstorm. You don't wanna see like falling, your house falling down for sparkle in your kitchen. You don't wanna see burning it up, okay? And now you've built that dream house. You've lived in it for a couple months and there's this light fixture that is not really in the right place. And you call in an electrician, he comes and he looks at it and is like, well, I don't know who built this house, but honestly, if you want this to move, I need to rewire the entire house. It will be faster for me. You don't wanna hear that, right? Now, how many times have you heard a developer telling you, well, I don't know who built this plug in but it's gonna be faster for me to rebuild the entire thing instead of just changing whatever you wanna change in there, right? Again, maybe we have something to think about. So how do they achieve that? They achieve that with some standards and code, you know? They can't build anything in any way they want. And again, checklists are very often mentioned in like construction on how to achieve that. So obviously, I'm not the first person who have been thinking about, you know, how, like, how can we do things differently? And a common answer to how the software industry should address the problem of quality and reliability, et cetera, is the Agile Manifesto. The Agile Manifesto is created around four foundational values, 12 supporting principles and you can read all of them on the official website, agilemanifesto.org. I'm not gonna cover all of them today but I would just like to take a few minutes to cover a few ones that are like really pertinent to this talk. The first one is individuals over interactions and interaction over processes and tools. It's all about human beings. Your code is gonna be created by humans, it's gonna be used by humans. It's really important to always remember that the individuals are at the center of everything. Working software over comprehensive documentation. It's all about working software. We need to build software that works, right? That seems logical but it's good to always, you know, keep that in mind too. Customer collaboration of a contract negotiation, that's probably the least interesting for us today and responding to change over following a plan. Responding to change, that's another really big one because I don't know about you but I've never seen a project that receives specs from the beginning and you ship the product a couple weeks or months later and it's exactly the original specs. That doesn't happen, never. So instead of fighting change, we're gonna accept the fact that the specs are gonna change and we're gonna embrace it from the beginning and build that into our process. 12 principles, we're gonna focus on five. Welcome changing requirements, even late in development agile process are an exchange for the customer's competitive advantage. Again, we accept change. Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter time scale. Truly agile shop, they don't ship every week, they ship every minute, hours. Companies like Amazon, Apple, Google, they all ship code in production every single minute. Code is going to production. I am getting lost. Working software is the primary measure of progress. Again, see how they're hammering the working software. Continuous attention to technical excellence and good design and hence agility. So this is all about our talk today. Continuous attention to technical excellence and good design will enhance agility. If we're paying attention to technical excellence, we're gonna enhance our agility. And simplicity, the art of minimizing the amount of work not done is essential. Do not reinvent the wheel, you may have heard of the concept of minimum viable product, trying to drill down your specs to really what your customer needs, you know. Get rid of the eye candy stuff, get rid of the what that would be cool to have, what do you actually need to do? And just focus on that, deliver that. On top of the agile manifesto, there's other things we may wanna consider. The cost of that code. So this Austrian firm came out with this number. I'm not sure exactly how they came out with it and I'm not sure, don't take it as a, you know, exact number, but they said that in 2016, software failure cost $1.1 trillion to the global economy. That's an entire Apple getting rid of every year because of software failure. Okay, IBM and again, if you look a little bit further into that study, you're gonna see a lot of controversy on how they came up with this number and the fact that it was written in 2008 or something like that. So it's a whole 10 years, things have changed, blah, blah, blah, but still. The cost of discovering defects after release are significantly, are significant. Up to 30 times more if you catch them in design than if you catch them in the design and architectural phase. Again, don't take that number for an exact figure, but it's pretty easy to think about it and realize, okay, if I'm fixing my bug during development, it's just me, my developer in front of my computer. If I'm fixing the bug into production, I have a customer who's wasting time contacting my support. There's a ticket, usually the customer doesn't give you any details so you need to contact, and you have this whole circling back, back and forth, it takes days to fix that bug. All of this is costing money to your business. And finally, there's the one that I like to call karma and happiness. No one likes to go to work and in the morning see an email with the customer, really pissed off because something is broken on their website, and on the other hand, as a developer, I really like to ship something and be proud of it and be like, wow, we did a really cool job. And wow, look at those numbers, it's performing well, no crush, it's really important. And to another extent, depending on what you're doing, I'm in higher ed, if I mess up something, I'm potentially messing up with some kids' higher education, they're in exam period, they're super stressed, and because of me, they won't be able to find whatever information they need to attend their exams. It's pretty important, you know. So what is good code? Let's try to define a goal. Good code requires communication. Again, let's remind us that it's all about humans and you won't be able to achieve good code without good communication. It can be with your team, it can be with your customer, it can be with someone who's working on WordPress that open source project you're using, it's all about good communication. Good communication is an essential component of good code quality. Experience. I'm not saying that an experienced developer necessarily writes quality code. I'm not saying that a junior developer can't write quality code, but writing quality code will definitely get easier with experience, especially if you follow, if you start using the principles we're gonna be talking about in a minute, those will definitely, some of them will definitely be a lot easier with time, as you know, as time goes. Another one that I like to mention is be reasonable. Once again, it's human. We're talking about humans. We're talking, there's gonna be some compromises. There's stuff that you will have to do that you won't like. And vice versa, there's stuff that you will want to do and will insist on and your colleagues, your customer will not like. It's all about being reasonable, trying to find the right compromises that are the best for your software, your business, your customers. Code quality. So Robert C. Martin in his book, Clean Code, defines code quality measurement in what the fudge permitted, okay? I thought it was pretty good. He's actually boring from Tom Welldow. I'm sorry, I'm butchering his name, a blogger. The thing I would like to point out is if you look at good code, there's still a couple what the fudge. Cause there will always be a little bit of that involved. But we're gonna try to limit it as much as possible. And some of those what the fudge are, wow, this guy is brilliant or he did some really cool things here. So if we think again about the agile manifesto and how we can define good code, I like to define good code as code that works, code that is easy to understand, code that is easy to maintain, and code that ships fast, okay? Now for all those items, I would like to give you some ideas of how you can achieve that in your daily process. Code that works. The first one is probably really obvious, but self-testing. Always make sure you test whatever you're developing. I cannot tell you how many times I've been reviewing code, I've been testing stuff that ship by developers and they clearly haven't tested it because it's already broken. It's just out of the box. It's like, it doesn't work. And there's no way on her that it's actually working anywhere on any computer. It's not just my computer or my browser. It's like, no, this doesn't work. So always, always remember to self-test. Especially when you've done everything right, you've tested everything and then you realize that the last minute, ooh, I forgot to do this. I'm just gonna change this one line of code and then I ship. And of course that one line of code you just wrote because you wrote it in a hurry and it's like, oh, that's the one that breaks everything. So always, always, always self-test. For that, we're gonna need a local development environment, something like DVV Docker. There's millions of them. There's millions of great WordCamp talks about how to set up a local development environment. But please do, please try to get one that is as close as possible as what you're using in production and do use a local environment to be able to actually do self-testing and self-test correctly. The next one, automated testing. There's a lot of debate about, you know, automated testing, is it good, is it bad because it's automatic, so it's, you know. And there's people who are on the other end of the spectrum saying every line of code should be automatic, you should have the unit test for every single line of code. I believe into, you know, again, be reasonable, be in the middle. A little bit of automatic testing, especially for your really key core components of your application. The stuff that when it breaks, it's gonna be really bad for you and really bad for your business. It's probably a good idea to have a little bit of automated testing on those parts. And the stuff that is less critical, et cetera, if you wanna skip a little bit of time and, you know, we all have pretty tight deadlines, et cetera, maybe you can afford to do that. Again, in the WordPress PHP world, we're gonna be talking about unit tests and on the front end part, you're gonna be using something like Selenium to do like UX testing, making sure your forms are still rendering correctly, your menu is not broken, every time you do a change or something like that, that's gonna run tests and make sure all those application works. A lot of people will have heard about PHP unit tests. And again, Selenium is one product you can use a lot of them to do that. It's really cool. If you haven't looked into it, really take a look at it, it's really, really cool. And code reviews. So that's one thing we've started implementing a year and a half ago with my team. We don't ship a single line of code to production anymore without having some appear program or reviewing that code. So someone else than yourself and the team is gonna be reviewing your code. That's probably the most difficult one if you're a single person team. But who knows? Maybe you have a good friend who's also a freelancer and you can exchange services doing code reviews with another freelancer that can be, this is awesome. This is really hard to implement because there's a lot of ego, there's a lot of human relationship into code reviews. You're gonna have someone else look at your code, start criticizing what you've done and there's definitely a learning curve there. But this is definitely what for us has made the biggest difference in terms of quality of code that has been shipping. Because now as a developer, I know that someone else is gonna be reviewing my code. So I'm gonna be paying special attention to doing things correctly because I like people who think I'm doing a good job. And we've caught so many bugs, so many things. And we're also having some really healthy architectural discussions really early. Like, hey, what did you do that like that? Have you thought that we're gonna need to do this, blah, blah, blah? And again, you're making changes and you're building your application very early in the process and making those changes a lot earlier than if you were just shipping, shipping, yeah, it works. And a couple months later, whoa, what's going on? Yes. Overreviews on stuff that's not yet ready for prime time? So... Can you catch those types of things? Yes, absolutely. So we break down our projects into tasks, into agile stories. If you're using something like Scrum, we use Kenban, so we use tasks. We drill down and so every single task has its own PR and every PR is code reviewed. Okay? Code that is easy to understand. Coding standard of conventions. That's a really good one. So developers spend way too much time arguing about commas, brackets, spaces, tabs, stuff like that. If you were at the talk right before, the speaker, I'm sorry, I'm missing his name, was mentioning that he and his colleague were debating on underscores and dashes for names and stuff like that. You don't have to do this. WordPress has something called WordPress Code Standards. It's, and you have a tool called PHP Code Sniffer. It's gonna scan your code and tell you all the mistakes. You've done. Don't spend time debating. This is a waste of time. Those people have already debated. They've already came up with a convention. Just take it, follow it, and you're done. End of the discussion. One great advantage of this is now you have your entire team working with the exact same syntax. They're all presenting their code in the exact same way. Another great advantage, if you have another WordPress developer that is going to be at some point looking at your code, external, like anything else, third party vendor, whatever, they're already familiar with this structure. They're already familiar with this naming convention, how the files are structured in your plugin, et cetera, because they've already worked with WordPress. So if you have never looked into this, please do, and please tomorrow start installing Code Sniffer and every single line of code you ship, please start following this. Okay? And this is for WordPress. You're working with JavaScript, with like most big frameworks nowadays have their own coding standards and they have their own linting tools that you can use to do this. But don't waste time discussing, how do we name our classes? How do we do this, blah, blah, blah. It's great conversation, but you have probably better things to do. Naming? So, naming is also really, really, really important. And don't be like, again, think about the humans. Name your functions in a very clear way. Name your variables. Don't name your variables F, X, things like that. Just a couple more letters. It's not gonna kill you and it's gonna save potentially a lot of time to the next dude who's gonna be looking at your code and trying to understand what the hell is going on in there, right? So use like clear, easy names to remember. And this goes together, readability over optimization smart. Don't be that guy who's like, yeah, but this is gonna save 0.003 milliseconds on compilation time. It's unreadable, but we've saved 0.003 milliseconds. Okay, unless you're working for Google, Amazon or something like that and those kind of optimization are making sense. Otherwise, just don't. Write something that you, yourself, are gonna be able to reread in a couple months and be able to understand what you've done there. Write that extra line of code. Write that if statement instead of that ternary operator that is kind of messy and that you, yeah, just go there. Code that is easy to maintain. Remember when I was talking about experience? That's definitely one that is gonna be big with time. That's definitely the one where you're gonna get better over time. Architecture, it's too many times and that's again, experience, especially junior programmers, you give them a task. First thing they do, they open the code editor and let's go, let's code. No, don't do that. First thing you should be doing is taking a piece of paper, taking a whiteboard, taking a walk, whatever you need. Think about what you're gonna be doing. Build it in your mind, build it in your head. Think a little bit. How is it gonna interact with the rest of my application? How is it gonna go on the long term, Xera? And how am I going to structure all of this? What, you know, a few minutes, you don't need to do this for days, but just take a little bit of time to organize yourself and your mind around what you're gonna be doing instead of starting coding immediately. Build for the present, design for the future. That's kind of, ooh, voodoo talk right here. You know, we're gonna try to minimize the amount of work we're gonna be doing. So when you write something, you should try to avoid as much as possible saying, oh, I'm gonna build this because, you know, we might wanna do that maybe later some days and you end up crowding your app with unnecessary functions and a lot of code that you build for the maybe someday. We will wanna do this, don't do that. Again, focus on your minimum viable product, whatever is absolutely needed to ship. But, but, and that's a big but. In WordPress, you have those fantastic tools, cool actions, filters, hooks. That allows you to change the behavior. You've, if you've developed for WordPress, you've used it, right? It's that magic, black magic that allows you to change anything potentially in WordPress and the way WordPress behaves. Suddenly, you can change completely the way it does things. Well, you can build the exact same stuff in your own code, okay? So if you have this function that is getting some data and doing some kind of filtering to it, maybe it's a good idea to put a filter in there. So the day you wanna change the way it's filtered, you can do it very easily using that filter, right? If you're building plugins for other people to use, it's very likely that those people will not love 100% of the work you've done and will want to somehow change a little bit the way you're doing things. Having a couple of well-placed action filters in there, that's definitely gonna make their day. So think about it, code that ships fast. Definitely using an agile project management solution. As I was mentioning, the big one, Scrum, is very, very, very popular. Our team is very, we have a lot of different people with different roles. We're not just a pure development team. We have designers, we have DBAs, et cetera. So Scrum was not really working for us because it's really developer centric. So we're using something called Kanban. Kanban is great, its big purpose is to limit the amount of work in progress. So avoiding to try to do 12 things at a time. And if you're anything like me, that's probably how you, for me, used to be working and maybe still working, like doing two-minute things at once, right? Kanban come from the auto industry, Toyota. So whatever you're doing, you can probably apply it to your business because if it works for software development, auto making, building construction, et cetera, like Kanban is used in a lot of different industries. So there's probably a way to use it for your own workflow. But again, Kanban might not be the best solution for you. There's plenty of them. Look at it and try to embrace one because that's gonna definitely make your life better. That's gonna allow you to drill down your project into really small chunks where you can do more easily code reviews, where you can do more easily testing, document it. Like all those steps are gonna fall in natural, like very naturally into place and it's gonna make your life a lot easier. Automation, and that goes a little bit with automated testing. Don't try to automate everything, but if there's this one thing you keep doing over and over again, and for some reason, because you're a very busy person, you keep doing some stupid mistakes, while doing the same things over and over again, maybe it's a good idea to look into it and to try to automate it. Because computers are really annoying, but they do something very cool is that when you give them instructions, they follow them to the letter. That's pretty great. So anyway, automation, again, don't try to automate everything, but try to identify some pieces of your workflow that are taking you a lot of time and try to automate those. The lazy. So we talked about it very early at the beginning, trying to minimize the amount of work done. This is your be a lazy. There's plenty of really good code out there already. So, and we're, this is WordPress, open source. Reuse, fork, extend, contribute. Before you start coding something, try to see if someone has already done something similar. Maybe they have, maybe they did it very poorly. Great, now you know exactly not what to do. So before you start coding again, try to look at what already exists out there. And checklist. Checklist, I'm gonna mention a book right after. You should definitely look into checklist. And when I'm talking about checklist, I'm not talking about your shopping list for Wegmans, right? I'm talking about process checklist. So we have this one process that we're doing over and over again, and we wanna make sure we're not gonna mess this up. Your pilot, whenever your airline pilot, right? When he gets into his plane, they never do anything just by habit. They have this checklist and check, check, check, check. That's how they're making sure they're not gonna forget to get the wheels out when you're approaching your airport or things like that, right? I'm sure you've heard of Sully, you know, the airplane that landed on the Hudson, exactly. Everyone has been, you know, Sully is a big hero, like the pilot, et cetera, et cetera. And he is, no, I'm not questioning the fact that he's a great pilot. But one thing that is very rarely mentioned is probably more than half of the success of this landing was due to the fact that his co-pilot was running all the emergency checklist twice as fast as most pilots would do it. And that allowed them to have the plane fully ready and for water landing, et cetera, while Sully was handling. So those checklists were as much, you know, as important as the pilot himself in this one emergency situation. So if you're ever alone to a website and forgot to uncheck the, you know, do not allow Google to index this website, right? Your customer is like, ah, my website is online for a month and no one can find me. Why is that? Oopsies, right? That, a checklist, that would have prevented that. And once you have your checklist, you know, it's not that cool thing, yeah, I've done it and now it's in a drawer and I'm never gonna use it ever, you know? No, use them, all right? Okay. So again, this was a very dense talk. If there's some of the topics you wanna dig through, clean code by Robert C. Martin, the what the fudge per minute, that's this guy. He's got a lot of great things about, you know, how you name your functions, humans in, like working with humans in software a little bit. Really great read. It's mostly a Java book. Like most of his examples are in Java. But again, that's not relevant here. Whatever language you wanna put there, that's, you can apply it to almost anything. I was talking about Kanban. This is a really, really good book from Eric Brechner. He's the head of Xbox software development. And he basically wrote this book where he explained how he went with his team from zero agile to full Kanban with his team. And that's really good read. I was talking about Checklist, a little bit of Harvard love. Atul Gawande is one of our like rock star faculty. He's interviewed Barack Obama and now he's becoming like the CEO of this healthcare, whatever, wrote this really great book, Checklist Manifesto. This is not at all about software development. He's talking about the Hudson River Plain. He's talking about the construction business. And he's a general surgeon and that's how they implemented Checklist into the operation block to make sure blood is here whenever you're operating in case there's a problem and things like that. So to make sure they have everything under control whenever you're going through a major surgery operation. Code Reviews, great article from Slack Engineering. How about Code Reviews? Very good and complex and covering the full topic. And thank you very much. Do you guys have questions? Why didn't you bring up the airline industry if you're not really going to publish things that you do in the airline industry such as linearizing code and avoiding human policies and logic? For example, nodding something as the first part of your statement. So I wrote the airline industry mostly for the Checklist example, but also for just reliability. And of course, there's again the same thing for the construction business. There's a lot of things they're using that we could be inspiring ourselves on. The introduction is not necessarily saying, you should be doing what the airline industry is doing because they're also doing a lot of things wrong. It's just saying maybe we... That's making more budgets than we do. They do, that's true. They also... They can afford to have a study to see what the customer actually wants. But they're arguably also building a lot more complex machines that we do. So... Anyway, so I'm not trying to say that you should be doing what the airline industry... I'm just saying we can look at other businesses and our industries are doing things and maybe there's some good inspiration for us. And those two were an example. There's probably a lot of other industries out there. Maybe some of them that you're more or less familiar with and that you can inspire yourself on how to improve your workflow to do better code. Any other question? I just wanna say, I'm not a developer, so I just felt like... I just felt like I walked away with so many great items from the stock, a lot of practical stuff. Yeah, I worked with a lot of developers. I would say a bit of a mess, you know, but I feel like you gave me some insight to how they kind of do things a little bit more. And I felt like it was some really good takeover, especially like the checklist piece. We're starting to have those talks right now. I'm trying to make those things happen. So I just really appreciated some of the stuff that you talked about. It was really practical. Again, the checklist manifesto, I get it for yourself, give it to your team, read it as a group, because it's really a really good, insightful book and that's really like, you're gonna definitely read that and tell yourself why have we been doing that forever? Like it's so stupid and so great at the same time, you're like, wow, I can't believe I haven't thought about this shit before. Now, would the checklist example be like, would you print one out for every app you're deploying or every, like I'm thinking for myself, if I have a customer, I would check with them, things have to go through. I would think I would have to keep that checklist in their file when I deployed. Here's my checklist. I know I did everything. Yep, yeah, that's exactly it. It's like you said, put it in the drawer. I put it in the file with you. If you're like a typical freelancer, the checklist I could think about is like your first meeting with the customer. What are all the questions I need to go through? When you're launching a website, what are the steps I need to go through? If you have a maintenance agreement with your customer, what are the steps that I'm doing every month in my maintenance agreement? Am I doing those, et cetera? And yeah, have them in your customer file or whatever cloud storage you're using. Or, yeah, whatever. Exactly, and just, yeah, have you, exactly. And it's also like, when you're working on a slightly larger team and organization, it's also kind of a self-protection system saying, hey, look, we follow the steps, like this, we've done things the way we agreed we would be doing things. And if something went wrong, well, we're gonna fix it, obviously, but things can happen. Exactly. But we've did things the correct way, or at least we agreed upon way. You agreed upon way, right? My name is incorrect, that's open for research. A question to follow on that. Do you find that your team defends a brief visit checklist? Of course, yes, yes, of course. First of all, because we're in the development business and nothing stays the same more than a month, so it's like... It's a living document. Yeah, exactly. It is, very much, very much. I think it's more for you and I, or whatever it is we work on, it would be. We're typically one and done type of software. All right, here's the project we're working on. The website went live. You're doing your SEO stuff. Yeah, this is what we said we'd do. I got everything done. We might revisit in six months and go, all right, what we do, all right, we don't need to do that because it's done and it's working. But this way it comes up. No, we did that the first phase. That's a new thing. But, and just to circle around, the checklist thing is not a software development thing. It's definitely a whatever you're doing thing. Agile practices are not a software thing either. It kind of started with software development. Now you see people in design doing Agile design, doing design sprints, et cetera. And the Agile ideas have grown to other industries now, clearly. And this is great because that's exactly what Agile was in the first place, was just looking at other people and say, okay, how can we do in the software business things, what are the best practices for us? So yeah, this is definitely, a lot of these things definitely can apply to other topics and not just development and even less web development. But yeah, I think it's been a really long process for us. For me and my team, we've been talking about this for a year and a half now. We're still far from being in the ideal world and the Agile scenario. But it's really, really healthy to sit down with your team, try to pinpoint some really problems and the way you do things and talk about it. And just like, hey, how can we solve this problem? And you usually have someone who's like, oh, I've read this or I've seen that or how about we try this? Yes, Charles. I would probably just add to that, if you just started connecting no cards on one wall, it's all of this thing. You saw this wall, completely covered with no cards and what we said we were currently doing and playing and doing next to the clock. And you realize, wow, that's literally impossible. You cannot do that. I don't know if this is about to say anything more. You may not work for you, but at least for us, help us visualize the message. No, absolutely, absolutely. And again, trying to limit what is absolutely critical for you, what are those critical features you absolutely need? That's a great way, having everything in front of you and be like, okay, I humanly can't do this in the amount of time that I have, so what can I get rid of? And that's very healthy to be doing that. Doesn't mean you will never do it, just means you're gonna do what's really necessary, ship your product and then talk with your customer or say, okay, now do you still wanna do this and we can add it and do updates and things like that, incremental? That's the way to do things. I don't wanna keep people from lunch, so if you don't have any more questions, I'm around if you wanna talk more. Thank you very much and have a good work. Thank you.