Agile Manifesto, Agile approach, software development

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season when we're looking at the Agile Manifesto. We're looking at ways to be better in the Agile sense of software development, become better developers because it looks like the Agile approach is one way to do so. So we're looking at the principles and discussing how these can help us and help us focus on making sure that not only becoming better developers, that we are providing better software to our customers. And of course, we'll mention that again because it makes sense to almost every episode. This all started the first principle with our highest priority is to satisfy the customer. So these things we are working on are essentially pointing to that primary objective, that highest priority. In this episode, we are all the way up to principle nine. And that one says, quote, continuous attention to technical excellence and good design enhances agility, end quote. This is where we start getting into the ideas of traditional software development are still valid. The idea of design and documentation and gathering requirements and discussing things with customers and all these things that we've done from requirements to design to implementation to test, those all are part of software. Agile does not take that out. And although it changes the focus, there are still some key things in there that we need to do. Tasks or steps in the process that are critical for success. Now this one's almost a little backwards. When you think about the Agile manifesto and the idea of Agile being, I'll call it the best, maybe not the best, but a better approach or a good or valid or valuable approach to software. Instead of leading with what agility does for the software process, this one actually focuses on how to be more agile. What is it that we do that makes us agile? What is it that goes into a team that helps them become a good agile team? And this one is something that actually should strike near and dear to our hearts because it is that continuous attention to technical excellence and good design. So this is the idea that we are constantly striving to become better. That there is an attention to detail. There's an attention to not going through the motions, but following the steps that allows us to become better, that allows us to become agile. And this is really a good pairing with the idea of changing requirements and those being a competitive advantage. Because if we pay attention to technical excellence, to solving the problem in the most efficient or the most scalable, most technically correct way, if we have good design that allows us to scale and easily maintain and create stable systems, all of that allows us to be more agile. Those core things, those critical steps are the ones we have to take in order for us to be able to embrace agile, to basically address the other principles that are discussed in the agile manifesto. If we don't, then we're going to end up with something not very good. We will otherwise, we will essentially build a house of cards. And as soon as something comes around that shakes the foundation a little bit, boom, everything comes crashing down. This is our don't take shortcuts principle. This is the one that says, it is important to focus on accomplishments, on delivering software, on delivering working software. However, that should not supersede technical excellence. It should not shortcut good design. Because if we don't have those pieces, if we don't create something that is technically the right thing, if we don't spend time on design, if we don't design well, then the flexibility that our system needs is not going to be there. It's going to be fragile. It's going to be something that once a change comes in, it's more likely to cause damage, to break the thing that we have. And so we've built up to this point, this idea that we need to build this very solid, stable, extensible system that we need to be able to handle change. We need to embrace change. We need to look forward to changes as a way to create something that has a competitive advantage. And if we get to this principle that says, well, wait a minute, all of that stuff is awesome. That stuff's great. However, you got to go with the things that do matter, the things that are truths, no matter what it is you're building. If you don't plan well, if you don't implement well, then you're not as likely to have something that's going to withstand change. If you slap together a little, you know, like the house of cards, you just stack a bunch of stuff up, it's going to blow over easy. If you take something heavier, let's say you build a, I don't know, build a Lego building or something like that, it's going to be a little more stable. You build stuff out of concrete and steel, it's going to be even more stable. And that's what we're doing. That's what we're saying here is that we're going to, we assume the value that agility has. And now we're looking at how we build stuff and saying, okay, given that, given the value of agility, these are some things we need to do to make sure that our software is agile, it is flexible, that it's not some static, you know, pristine thing that as soon as you get the slightest blemish or the slightest wind or whatever, it destroys its value. We have to build something that can weather the storms that are going to be out there. And yes, I know, I apologize, I'm going through so much hyperbole and stuff like that, but all these analogies, but it's because there are so many examples out in the real world of this principle that we need to keep that in mind when we move into the software world. And maybe even more so because if we don't plan out something simple like mowing the yard, you know, you take whatever path you want. Yeah, you may overlap a little bit. You may, you know, maybe you miss a spot or something like that. That's not necessarily a huge problem. However, in the software world, if you have a requirement gap or if your design does not handle certain valid inputs, you may literally have something that's useless. You may destroy all value in it. So we need to, instead of just, you know, we can't just like slam this stuff home. We still need to, while we're doing all these other things that we've talked about, you know, trying to create work in software and delivering stuff regularly and, you know, grabbing the communication between the development and the users and all that kind of stuff. That's all, those are all things we need, but we also need to stick to the thing that started it all, which is technical excellence and good design. If we don't do that, we're going to struggle. And so the agile kinds of, I guess the tropes basically of, you know, we don't really worry about documentation and things like that. This goes back to that system. Wait a minute. It's not just about writing code. You still need to write good code, clean code, follow the best practices. And you need to design what you're doing. You need to think through this stuff. You can't just start slapping code into a system and say, okay, we're implementing, we're good. This actually says the opposite of it. Essentially, it says, no, no, no, you need to step back and you need to think about what you're doing. You need to design whatever it is you're building, not just code it. And you need to follow best practices, not just slap code into a system. So even while we are trying to remove the shackles of administrative stuff and bureaucracy and red tape, we're still pulling pieces out of that and saying, well, wait, you know, don't throw the baby out with the bath water. Let's not just assume that everything we did is wrong. There are some key things that we got out of these processes that we still need to have. So while maybe we don't need documentation, the communication that it represented does need to be, still needs to be there. It is still valuable, even critical. And so in this case, we're saying that as far as design is concerned, it's the same thing. Don't short circuit the process at the cost of quality. If you're going to pull stuff out that is not, and this, you know, we talked about this a little bit as if you're going to pull something out, you need to pull out the stuff that is not needed, the stuff that is busy work, the things that should be done that need to be done. They still need to be done. We aren't going to cut corners there. savings and our improvement in timing and shorter time to market, stuff like that. That comes from jettisoning, jettisoning, jettisoning, the busy work, the things that don't really contribute to working software and satisfying the customer. We are not going to get rid of or short circuit or cut out the things that do contribute to that, that do contribute to good quality working software and satisfying the customer. And we're going to, in this principle, we're going to specifically call out that technical excellence at bells and whistles, we don't need, but we do need a proper technical approach and technical solutions and we need good design. We can't throw that out. We can't just write code. We have to think about it first. Now this is, this is a pretty short principle, but I think I'm going to leave it at that because it, it really almost does stand on itself. You know, and although I've thrown a lot of examples out there, I think it's one of those that either you either you embrace this and you will strive to become a better developer or you don't. If you don't think that technical excellence or good design have value in many ways, then you're going to struggle to go forward. You need to, you need to really, I think, take this one to heart. So I'm going to let you, I'm going to cut you loose and let you ruminate on that a little bit. I'm going to let you think about how that may apply to what you're working on and maybe your approach, maybe even your daily approach. Do you, you know, maybe, and sometimes I know I do this sometimes, do you maybe jump into coding a little too soon where maybe you should take a step back, take a deep breath, do some sort of a design time or, you know, put some sort of design effort into what you're going to do and then worry about the code. I think that's a little bit of a puzzle to think about, but whether you do or whether it just like goes in one ear and out the other, that's okay. Because I'm still going to help that you have a great day, a great week, and I'm still going to talk to you next. Thank you for listening to Building Better Developers, the Developer Noor podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon and other podcast venues, or visit our site at developernoor.com. Our journey is still progress, so let's keep moving forward together. One more thing before you go. Developer Noor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.