Software Methodologies: Thrive in Agile, Waterfall & DevOps

Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season of Building Better Developers, Developer Noir, with AI. Yes, we're going back through a past season. We're taking those topics, throwing out the AI and see what it says. So far, it's actually been really interesting. It's been very much in line with a lot of the things we've talked about and the 10 things that it suggests. We have never gotten through all 10 because we have comments on every one of them because that's who we are. More specifically, I am Rob Brodhead, one of the founders of Developer Noir, also the founder of RV Consulting, where we are that company that sits down beside you and says, Let's look at what you've got as far as technology is concerned. See where you want to go with your business. And we're going to craft a special recipe and help you build a roadmap, maybe even help you implement it for your technology so you get a better return on investment through integration, simplification, automation, even innovation. We will find ways to take what you've got. My favorite latest one is take that junk drawer of technologies you've got and turn it into something that's actually useful so that you're not sitting there at the end of the year going, Where did all of these licenses and all of this money go? And instead, you're counting all those bags of money that come in because now you have a smooth, slick process and you're leveraging technology instead of being, you know, hemorrhaging technology even. Good thing, bad thing. Good thing was, took, got to take a week off, sort of, about a week or two ago. I spent some time away from home, a little bit different, you know, change of, change of scenery and things like that. Had a couple of days that were partial days, essentially, and things like that. Were able to do some, check out some of the areas around there and some, you know, nice little walks and exercise and good things like that. Bad thing about that is somewhere along the way, picked up some sort of crud or something like that. So now I've got that deeper radio voice that hopefully I will not be coughing through this too far. That being said, the other guy, the guy on the other end is now apparently on the other end of all of his allergy issues, but we'll see how that goes. Michael, go ahead and introduce yourself. Hey everyone, my name is Michael Moulache. I'm one of the co-founders of Building Better Developers, also known as Developiner. I'm also the founder of a company called Envision QA, where we work with businesses and understand their problems and help them find a solution. We do that through essentially a QA mindset. We take it, walk through the processes of your company through a user's perspective. We essentially do an assessment of everything within your technology stack and determine how you're using your software and if it's working for you. If it's not, we help you customize the solution that fits your needs, either help you find over-the-counter software or build you something custom to work with your systems and hopefully improve your performance and customer satisfaction. Good thing, bad thing. Well, good thing on my side, as Rob mentioned, I am over my allergies. I am past my part of the season and part of that is due to the fact that we have had sunny weather for almost a week. A few rainy spots there, but lots of sun so I can finally get over the crud that I had. Bad side of that, I am away from my house this week because my daughter is at Bonnaroo, which is a Woodstock kind of thing in Tennessee concert. So I get to dog sit for a week amongst all my other business tasks. So I get a multi-test this week. Always a fun thing. Never hurts to have a few pets, at least so I've heard I had kids instead. Moving on. So the topic we're going to talk about last time around was titled, Bridging the Gap, how developers can thrive amidst differing technologies. So we throw that at AI at chat GPT. And of course, it is very impressed with us. It starts out with that's a great topic, very relevant in today's multi methodology hybrid tech teams. There's some things here where you can see where AI is like, as they say, over egging the custard a little bit, throwing a couple extra big words out there to make it impressing. Let's go into their outline and key talking points. So set the stage. What are differing methodologies? Quick overview of common methodologies. Agile Scrum, Waterfall, Conbomb, DevOps, Safe, Exploited White Teams often end up mixing them, Enterprise, Constraints, Legacy Systems, Client Demands, et cetera. Now this is one that I think we really did start with a very brief definition. We didn't go as broad as they said there. But it's basically you sort of want to set the table for something like this. This one, I don't think we have too much to talk about. So let's move along to the next point and see what they say. This is where the common struggles developers face. Context switching between styles, for example, Agile Sprint versus Waterfall Milestone Mindset, misaligned expectations, definition of done or documentation depth, communication challenges when processes are not uniform, friction from leadership or other departments with different cadences. That's four or five episodes right there, I think. The first one, I'll just dive into the first one. Context switching between styles. We talk about switching your projects on a regular basis where you maybe have two or three projects at a time. They may be different technologies, different environments and things like that. And there is that mental cost of switching from thinking about, for example, JavaScript and putting semicolons at the end of your lines or Python where you don't have any and you have to make sure you get your tabs right or Java where you're worried about case sensitive versus maybe DOS where you're not. Things like that. Okay, DOS, there's not a lot of people out there, but I'm going to throw that out there just because I can. It is, I think, more jarring to do it from a methodology point of view. This is something I don't think we've really talked about it from the higher level methodology point of view, but I'm going to throw this right at you as the thought of it because I'm sure you've been there as well where we're working a project. Maybe one customer, it's agile. The other one's waterfall. Maybe one's Kanban. And this is even amongst agile. Maybe you've got a scrum that's like every two weeks you do a sprint, another one you do every three. Some of you do retrospective, some of you don't, things like that. So what are some of your thoughts on the context switching? So there are pros and cons to this. Let me start with the pros. So one of the things that I enjoy about context switching is if you're working out multiple projects, especially in the same language and in the same kind of business class, you typically can run into burnout where it's like, oh, I'm working on this and I switch gears. I'm still working on kind of the same issue, same problem. One of the things I like about working on multiple projects in different contexts or different languages is it allows me to mentally shift from one mindset to another. Let's me take a break from what I'm working on over here. Let's me get over here and work on this. Now, the negative side to that with switching context is, like you said, kind of that mental shift. You have to make sure that you go from this language, you go to this language, you got to make sure you got the syntax right. If you're starting on a new project that you haven't worked on the language in a while, that uplift is going to be a little tedious at the beginning. Now if you're going back and forth between languages that you've worked with constantly, it's less of a contextual shift, so to speak, because you're in it enough that you can go from this, you can go to this, go to this. It's kind of like being bilingual. If you can speak Spanish and English really well, you might be able to speak like French, but if you took Spanish for four years in college and it's been 10 years, yeah, you might be able to understand it, but you're not going to be able to jump in and start speaking it real well right away. It's kind of the similar kind of context with programming language. It's still a language. So all I can say is make sure that if you are jumping projects and you're dealing with this contextual shift, make sure that you have the tools in place to do it, because if you don't, not having the right tools in your tool belt is going to be another kind of downside to multi-switching, because you're going to be like, oh, okay, I can use visual code. Well, visual code, if you go from like Python to Java, oh, what libraries do I need? What plugins do I need? You might be better off just downloading like Eclipse or IntelliJ to quickly jump into that language. So just some things to think about. Your thoughts? The tools is really interesting because I actually like when I'm crossing languages, and this is not so much with a methodology side, but when I'm crossing languages, a good point, I actually like to stay in like a Visual Studio Code or something like that. So I'm in the same general context. I sort of know where windows are and things like that, and quick keys and stuff like that. There is a benefit though of switching them so that there is, when you're looking at it, there's something visually different. So you're like, oh, I'm working on project X instead of project Y. Now I'll even do that in the same language sometimes. So I've got two projects in the same language. I may work one. Let's say they're both Java. I'll work one in Eclipse, then another one I'll work in IntelliJ or something like that or Visual Studio. Now interestingly enough though, this week, we've been working on some things. You've broken your local environment because you're using the same environment and the same tool suites. So to me, that's kind of a trade off if you try to stay in like Visual Code because if you do something for one project, you could potentially break yourself in another. Whereas if you have the two, you separate the instances, so to speak. Well this was actually, this is not my environment. This is my operating system. This was the underlying database. This is where that's a whole different concept where maybe it is better and I've thought about this a lot in the last week, that it maybe is better to just run through containers and stuff like do your development there, have your environment up, spin it up, do what you need to and go from there because sometimes you get operating system updates and everything breaks. I'm not going to complain about Brew and Mac, but I just did. It can cause you some issues, especially, and it can cause you issues when you're crossing languages, you're crossing databases and some other stuff. You'll get libraries that can, you know, that updates you don't want to. And it's not just, it's not just Mac and Brew. I know Windows, that's part of why I left it. I had too many DLL Hill situations in my life. Moving along though, this next one, misaligned expectations. For example, the definition of done. Oh my gosh, this is the quintessential discussion in every project somewhere along the way. If it's done right, no pun intended, you talk about it early on. What does done mean? What does it look like? If it's not, then what's going to happen is somewhere along the way, there's going to be an argument slash discussion slash World War III beginning over what does done mean. And usually it is when you cross like business analysts versus project managers versus QA versus developers, because they don't always say the same thing. They don't always think the same thing. And then you have the user who doesn't always think the same way. And when you say something is done, that needs to be clarified. This is something that we've talked about in various cases over the years. One of them is definitely when you're dealing with a customer, know what done means and make sure you're clear what done means to them because you don't want to be in a situation where you say it's done and they don't think it is yet. Or the reverse when you say it's not done, but they think it is. So they're like, ship it, put it in front of everybody. And you're like, no, no, no, no, no, no, that is not what that is not kosher. So even especially with methodologies, because there's a very different way that we approach things if it's waterfall versus if it's agile. What I hear is that agile is almost always that like that 80-20 Pareto principle kind of approach of like, we'll get there, we're mostly done, we can clean it up in the next sprint, things like that versus waterfall. It's like it has to be done code freeze and then it better be solid. You better have all your pieces, all your ducks in a row. Thoughts on that? Boy, that's a can of worms. So having a lot of experience on the testing side of things and doing a lot of user acceptance testing integration testing, unit testing. From a tester's perspective, the definition of done is different than if you're doing like unit testing, because unit testing, you're testing a function of code, you're testing something behind the scenes. Whereas when you're actually writing these tickets, you're creating features for the user, you're creating something within the application for people to use. And the definition of done isn't always visible to the user. Sometimes it could be as simple as something is created behind the scenes, a job runs, something is created in the backend. But these things need to be defined in such a way that it can be tested, that you can essentially check off. It's a checklist of things to do. The best thing I can say, and I say this all the time with testing, is think of a recipe. All the stuff that goes into it is all your ingredients, that's all your code. What comes out of it is that those steps to actually produce the food. So you have the requirements, which is kind of that here's your overview of what it is that you're making, you're making chocolate chip cookies, so you should get cookies. Your ingredients are essentially this is what needs to go into the code to build it, chocolate chips, sugar, flour. And then the recipe or the steps to produce it is essentially your checklist. Okay, did this get mixed correctly? Did this go into the oven at the right time? Did it come out burnt or did it come out the right way? That's essentially to me the way you need to tackle definition done or within a ticket. What is it that you're doing? What is the output of what it is we're asking you to do? If that's not defined, as Rob mentions, it's going to get to the tester and they're going to be like, well, what did you do? And the worst part is if it's not defined and the developer does something off task or out of scope and it's not documented in the ticket, you have no idea testing. You're going to go test it and it could be something totally different than what the ticket says. Your food example gives me another, I think of something similar. If you want to talk about what the, think about how argumentative it can be to figure out what done is for a feature, sit around with a bunch of people from different parts of the country and ask them what done means as far as steak is concerned. And you will find not only very different answers, people that very much want it done a certain way. And that's where I think we get into, it's almost religious issues arguments when we talk about it from developers to testers to project managers to users and things like that, that we can really get caught up in the semantics of that, the syntax of it. And so we need to make sure sooner rather than later that we walk through what that is. And that's also so much tied to methodologies. And that is where you really have to think through it. You're going to have to shift your mind a little bit to say, okay, what do I need to get done to mark this ticket complete or move it on to whatever the next phase is. Let's go ahead and move on. I'd say there's a lot of good stuff in this one. So they get into mind shift, mindset shift from methodology purists to adaptive professional. Encourage developers to value principles over process. For example, delivering value, team collaboration, share real world anecdotes where rigid adherence hurt collaboration. So being methodology bilingual, understanding how different systems work, even if you don't prefer them. This, these three bullet points right here. This is basically the agile manifesto. Principles over process. There is, this goes back to something we brought up, I think even in this specific episode is it comes down to why, why are you building this application? Why are you solving this problem? What is the solution that you're really trying to get to? Because yes, there is a lot when you talk about a methodology, there's a lot of rules for lack of a better term, rules or guidelines on how to get there. But the bottom line is you need to get there. It's just like, you know, you can jump in a car and go from one end of a country to another and there's a lot of different ways you can go and some are going to be better than others and cost more or less and things like that. But the goal is to get to the other end of the country. It's not necessarily that, hey, we turn left here instead of right and things like that. And I think that is something that I, too often I've been in situations where people get caught up in the methodology side of stuff and are not thinking about, we still have a, we have a goal that is not serving the methodology. It's actually serving our customer. Thoughts on that? Yeah, so it's really funny. The principles over practice, you know, what are you building? Why are you building this? When you start out on a project or start out on the journey, you kind of have a end goal in mind. You kind of have an idea. But the problem is as you go through the project, either customer expectations change, requirements could potentially change, and you might lose yourself in the weeds versus where you're going. You could get distracted. It's the constant example we throw out is, you know, why is this button purple? Why are you spending hours on a color when the application isn't done? It's you know, you gotta ask yourself, is what I'm working on working towards the goal or am I just working? Basically am I being busy to be busy? Am I staying on task? Am I working towards something? We run into that all the time. And that's one of the clearest things. It's almost like, you know, the multitask thing. It's like you can't really work on multiple tasks simultaneously. You can perceptually wise work on multiple things at the same time. But really, you're stopping your focus on one thing to work on another. And then when you shift to that, you're stopping your focus on that. Now, if you say you're multitasking and you shift from this to this and you're still thinking about this, then you're not giving this its full attention. So try to make sure that what you're working on is going towards that goal, what you're trying to build and not getting sidetracked in the weeds on something that is important but maybe not important now for the end goal. Yeah, it's just like red tape anywhere it can be. Is it you can get the process can be what you're serving as opposed to the customer and the end product. Moving along, because there's great points there and I don't really have much to add. Practical skills developers should build. Communication. Learn to ask the right questions in different frameworks. Great one. This next one, which is going to be a full stop right after this. Documentation agility. How to write just enough without overdoing it. Now this is this is probably one of the most valuable skills for a developer to have is to figure out how to write enough or actually developer, business analyst, project manager, scrum master, whoever is anybody that writes tickets, documentation requirements, how to put the right amount in there so that you are covering the things that need to be covered. And you're not wasting people's time with a bunch of extra stuff, which actually goes back to the original thing I was saying about AI is where it was like it could have had a much shorter answer, but it put a lot of fluff in there because that's part of what it does. And honestly, if you look at a lot of blogs and stuff like that, there is a lot of fluff in those things as well. People are spending too much time trying to impress people with the more than four letter words that they know and all these things and write to a 12th grade level or whatever it happens to be, as opposed to just be concise, get the point across. Just like I haven't done. I just added a whole lot of fluff right there. It's better off to say make your point, make it clear and move on. It's that simple. Thoughts on that? The thing I'll add to that is one of the biggest problems with documentation is the multi-sources where documentation lives. At the beginning of a project, it should live in one place, be it Dropbox, one folder, whatever the requirements gatherers gathered, it should go in one place. As the project goes on, this is one thing I've kind of adopted over the years. Your code, documenting your code needs to be the source of truth. If you're adding Java docs or any type of comment documentation in your project, it should essentially go from the requirements to the code. You should have somebody building that with your code at the end. So you essentially can always look at your code and know that this is the source of truth. If you try to jumble the two and maintain a secondary requirements document outside of your code, that's fine, but you have to be very rigid about it because if you don't stay on track, your code could go one way and your documentation goes another. But if you keep the documentation in your code, then essentially as you make changes, you should be updating your documentation and then everything's in sync. And that is a perfect segue into a great way to help document your thoughts about this is to send us an email at info at develop an order.com. We appreciate your time. We appreciate you. You sit here and walking through these things with us. I highly recommend that you do a process, spend a little time with something like this, take some thoughts, throw them out to one of the AI engines, preferably a couple of different AI engines and see what kind of stuff comes back because we are getting into a world where yes, AI can help you be more efficient. It can help you get stuff done faster, but you also need to be able to recognize AI in some of its fingerprints and some of the things that it does well and the things that doesn't do very good so that you're able to leverage it even better and also maybe not get caught up by somebody that's AI generated something and you think it's good and then you realize that no, it actually isn't. It's going to help you inventing not only your own work, but that of others. This actually is not AI generated. I'm a real person. He's a real person as far as I know and our intelligence, it may not be that great, but we are definitely not artificial. That being said, I'm going to wrap this one up. Thank you again for your time. Go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.