The Importance of Properly Defining Requirements

Welcome to building better developers, the developer 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 season talking about problems. We're just like moaning basically about work, but not really because we're also talking about how to advance your side hustle, advance your career, advance some of the problems that you're running into. This time in particular, we're going to talk about requirements. We're going to get back into this discussion. We've touched on a few times, I think even already in the season, but want to get dig back in because it is painful. It is something that can be a pain in the butt to deal with. You need to be sure that you're, you need to be comfortable getting the right requirements and you need to be detail oriented enough to make sure that you're looking at whether it's a ticket, whether it's a design document, requirements document, depending on how things are delivered to you, that you are looking at that and digging into the details and thinking through it and where there are potential assumptions, you ask questions about it. And first, before we get too far into it, I'm Rob. I'm going to invite, just welcome you back, Mike. We've been here the whole time, but throw this over to you. You can introduce yourself a little bit and we will dive into our requirements discussion. Sure. I'm Michael Moulache. I'm founder of Envision QA and co-founder of Developriner. And like Rob, we're both developers. We've been in the industry for many years and requirements is a key issue that we constantly run into when working on software or even testing. One of the biggest problems we have is lack of requirements or insufficiently defined tasks that are given to us that essentially could cost the company time, money, and have an insufficient product be developed. And I think that's where we want to start is the funny thing I was saying about this is we did a season way back. It's been a couple of years. I forget what season it was, but it was a season of mistakes. It was basically walking through, it was learning from mistakes. And one of the things that we got at the end when we're sort of summarizing whatever it was, the 30 episodes of different problems and mistakes that have been made, one of the things that came around was communication, was just being clear on what you're building and the customer having that drawing out of them, clarity on what they need. Because it is, as we mentioned way too often, there's people who are like, hey, I want to build Airbnb for, you know, pet houses or something like that, whatever it is, it's just, it's I want Uber for tricycles, whatever it is, is they've got something that exists. And it's a good idea in a sense, because like, hey, let's take this thing. It's already there. Let's flip it on its head a little bit. And we're going to rebrand it in this other direction because that's not being served. Awesome. But it's the then they come to you and say, well, it's just. Just look at Airbnb and then bake something like that. It's like, no, that's it's like Google. Just make something like Google. It's like, okay, I can write a page where you're going to put something in there and it'll give you some results. That is not Google. Behind the scenes, there is insane amounts of stuff behind there. So we need to recognize that and to talk to a customer about that. And instead of the what's so often we get the requirements are like, well, you know, just do it like this or it just looks like that is actually get into the, okay, this is what you're showing me. Let's walk through this. Here's where we start. How does somebody get here? Once they're there, what do you envision them doing? Okay. When they do that, should there be a notification? Should there be a warning? What if they do it wrong? And just follow through that. And then what kind of approach is so that whenever they tell you, they're like, okay, we're going to do this. Okay. And then what happens? And then what happens? And then what happens? What if this happens? It's that conversation. It's building out that it's world building in a sense, but it's just for their problem and their solution and talking through what those requirements are. Really starting to draw that information out, because as Michael said, if you don't, you can go on a very different journey than they need you to go on. And it can be very expensive. It can waste their money. It can waste your time. It can cause bad blood between you. There's so many challenges that can come from not having the requirements. Now, I'm going to throw this to you, Michael, but then I'm going to come back. And I do want to talk about. What happens when it's intentional that you don't almost and where you can go with that. But first, let's let's stick to the that requirements discussion, that conversation. So the way you laid it out is the typical way we as developers or engineers go about or should be going about defining the requirements of the ticket or at least reviewing what it is that the customer wants to make sure that what is being built meets their requirements. However, from a testing perspective, we should take that step one step further and then actually ask, why are we doing this? Why is this needed? And if you ask those questions, you could even determine that, oh, what we're trying to build isn't even what the customer wants. Because I've run into situations where like the business owner or the project owner or even the customer thinks they want one thing, but it's something completely different. So the requirements for what you're building, yes, may be flushed out, may be right or may need some additional tweaks, but they may not even be the right requirements for the solution. You might need something totally different. So there's a couple of things to kind of unpack there. So one, understanding what the end result is, not the end result from the task. But what is it that the customer or the requester wanted before the ticket was created? What is it that they are expecting to come out of this change? Walk back from that, then go to the requirements and say, OK, this is what the end user wants. This kind of goes back to that tree swing model that's all over the web. You know, customer wants a tree swing. So you go back and say, OK, so what is it that you want to do? Well, OK, I want to be able to sit on a tire, on a swing and just swing underneath a tree. Now, the requirements that could have come to the developer could have been, OK, we need to put a swing in the tree. Well, what kind of swing? You know, is it a typical two ropes and a board? Is it a tire and or a string in the tire or just a rope? Right there, there are three possible implementations based on a very vague requirement. So you have to really flush that out a little bit more. Now, in the real world, typically we're under deadlines and we've sales or marketing has already committed us to X, Y and Z. Here's the requirements run. Oh, by the way, it's due next week. You've got to rush to get those changes out the door. That can lead to unintentional consequences where what you're given is it again, is it what the customer wants? So that's one thing I would really stress is not only look through each step as to what is in the ticket, but make sure you understand what the ask is of the ticket or the requirements that are coming to you. And I think that's why you have that discussion around requirements, even as in minimize assumptions, as talk to people about what what is it that you want done? What is it? And it really goes back to what is the problem? Do you think this is going to solve? What is the issue that we need to deal with? Even with bugs? I mean, we get this all the time and we're usually better with bugs because somebody will say, well, it doesn't work. OK, that doesn't help me. What doesn't work? How did you get there? What does working look like? When it works, what do you expect? You know, what is the expected outcome? It really goes to the why do you think this doesn't work or why do you state it doesn't and what does a solution, what does fixed look like when it's fixed or repaired or corrected or working or whatever it is? What does that look like to you to make sure that we can get from where we are to where we want to be? And even if you're in, even if you're and I think even more so, if you're under deadlines and under pressure, it is so much more important to start with. Let's dig into this. Like a lot of times it's like sit down, talk through the tickets, the requests, the requirements or whatever it is. And really get into that conversation. And I know that there's. You guys are rolling your eyes because there are those places where you just get stuff, the CEO comes in and it's like, hey, here's what I need you to do. And I have to have it next week because I got a sales call. Cool. Awesome. You're going to have to give us more. And he's going to be busy or she's going to be busy. And they're going to run off and be like, no, you guys just go make it happen. It's like, well, no, either you need to talk to us about this or we need to have access to the customer you're selling it to or something like that. Because then. We may not have enough time to build this. We may not have what we need, but there are opportunities like there's triage, there's MVP. I will I go back the first time I got my name in a book as a author of, you know, of like software and stuff like that. The original product we built and it was two of us basically. We got the idea on like 2 p.m. on a Friday afternoon. They were going to a salespeople were going to a conference. They were leaving that night. They were going to have stuff all day, booths Saturday and Sunday. And we worked through the night through something at them based on this, this new concept. And then they gave us feedback through the day. We gave them updates. We did it again Sunday. And we had. A really like big on the MVP, maybe by that Monday. But it was basically we were it was really more like duct tape and bailing wire. But it's also get Brink comes to the idea of building a clickable demo of some sort, something that you can put in front of that CEO, that customer, that whoever it is and say, this is what this is going to look like before you've invested too much time into it. Give them what you can. So they have an they have a sense that you can set the expectations of this is what we're building. This is what you're going to end up with. So they can either say, yeah, that looks great or no, I've got this whole other thing that I want to be done and then say, OK, well, work with them within that. So it's not. And sometimes it is. I think we push back too much because it's it's a we don't want to do. We we are too strongly against the approach that they're taking. And so we we we sell it as that it comes across as that. It sort of is a us just poking holes in their their requirements, but really, we need to be pushing towards instead of pushing back is dragging them forward and saying, OK, I'm hearing these things. So how about we do this? How about we do that? Hey, we can do this. We can do that. We can sometimes it's like, hey, we cannot provide you this, but we can go provide you this other thing that gives you essentially the same solution. The one I think I've mentioned before that is like the. The quintessential project gone bad because somebody thought they needed they they were too much into the implementation was we spent, I think, a month building a solution to pull down. This is dealing with like hundreds of thousands, millions of rows on a Web page and being able to like, you have to be able to page through them and you have to be able to page through them quickly. The page has to come up quickly and like all the time. A hundred thousand, a million rows. There's just to display those on a Web page is just a lot of stuff. And even if you're paging it, whatever you're doing, somewhere along the way, you're having to pull all that data into the page. And whether it's going back and forth, however you do it. And it was just it was not fast enough. There was nothing close to it. And we went around and around and around and finally got down like really. And part of it was because it was under under pressure. So initially, OK, we're just going to get it done. We're going to make it work. We're going to make it work. And finally, sort of like, wait a minute, back this up. Why do we need to present a hundred thousand rows to a customer? And it finally got to what we need to do is we need to get to the last page and have at the bottom of that page account of the number of rows. So what they really needed, they didn't care about any of the detail. They cared about that one number. It's like, why don't we just give you a summary report that's one page has that number like three others like, oh, you can do that. Yes, we can do that. And it's so much easier, so much faster. And it's it is it's somebody was so focused on this is what we need and this is how it needs to look. And it was just this is where you are a better developer instead of just a coder. This is where you become a developer and you're not just writing code is instead of just go do it as you used earlier that, you know, dig a hole. OK, dig a hole over here. Oh, wait, that's I want that hole there. And the next thing you just dug a lot of holes instead before you get into digging holes and tear up somebody's yard. OK, why are we digging this hole? Because we want to get to a well. OK, well, let's first make sure that when we dig a hole, we're going to actually hit something that's got water, you know, or whatever it happens to be. Those are the things that we need to push back. Particularly as we get into, you know, when we're starting out, we're paid to just write code, basically. We're not paid. Some people think we are, but basically, we're, you know, we're paid pennies. And it's basically to go write code. But as you get further in your career, you are paid to be even if you're an employee, essentially a consultant, a somebody that is bringing something to the table other than writing code, that you're actually able to push stuff back and say, hey, yeah, that's an important problem to solve. Let's think about solving it in this different way, because it would provide we can get you solution faster or better or whatever that happens to be. Thoughts on that? Yeah, I run into that a lot. And I agree. This is one of those things where if you're just starting out as a coder, you're typically just going to jump in and you're going to try to do the solution. You're going to try to do something to make it work more mid level. You're going to be asking a lot more questions, but typically you'll still probably start and then have questions as you go along and more at the higher end, the engineer, the architect levels. You're going to be asking lots of questions before you begin. With this in mind, though, with a lot of the software approaches, especially with agile, where you go through the process of kind of pointing tickets ahead of time, you review tickets and refinement, but you don't technically get to those tickets for a month or two or even six months down the line. And your requirements can get stale. Now, they may be flushed out at the beginning. But what is your ticket? How would you handle the approach of taking this ticket that we already have and we have flushed out the requirements? But maybe there's been some additional changes in other tickets that now make that one obsolete or whoops, now it's not going to work the way we anticipated it. That's the whole point of really to me, that's like really the whole point of agile and having backlogs and things like that is because you you do. You re-groom. You don't just like pull tickets when you're grooming. You're actually reviewing tickets in the agile approach. And let's just stick with that as an example is that you're looking back through these and these could have been put a year ago. And I have been in those situations on more than a few times where you've got some that's been sitting there for a long time, like months, maybe a year or more. And now we're finally getting this ticket and we're like, OK, this doesn't make sometimes a lot of times, actually, it doesn't make sense anymore because things have changed so much that it's either sometimes it doesn't even make sense at all. So you just throw it out. And sometimes if you've got a good scrum master or product owner, then that they're in their interactions, those things will just disappear when those things are no longer needed. But sometimes they're needed, but it's very different from the original description, definition and requirements. And in those cases, is it goes back to just like you would with any other one. You're going to look at that and say, OK, you're telling me that we need to do A, B, C and D. Cool. OK, A, I get, but B, C and D don't make any sense in what we have. So how do you see that working in our current environment? You know, it's those kinds of questions. It goes back to ask those questions. And again, you don't have to go back and you don't want to. I don't think you don't want to go back to the the backlog tickets every time and keep updating those. But when you get to a point where you're going to pull one forward, that should be part of the discussion is, is this still valid? If it is, are there changes to it? Are there additions? And and keeping those fresh, basically, particularly if you are moving along in an agile approach where things are changing as you go. Now, if you've built something, you're more like a waterfall that has been very static and everything was laid out beforehand. Then you may not have to worry as much, but somewhere along the way, you do still need to do that. And I would always do it. As you like, as a just in time kind of approach, like, I'm going to work on this ticket before I'm going to work on it. I'm going to review it. I'm going to ask my questions about it, because even if the requirements haven't changed, your understanding may have changed. And so the questions you have may be very different than you would have had a month ago, six months ago or a year ago. Right. And it's kind of interesting because this kind of gets into an approach. I've wondered for a while, should you be putting tickets out there or defining requirements for a coder or developer to work on six months out, a year out? Should you keep that as an epic at a high level? And then when you get time to actually sit down and work on it, yes, you flushed out the high level requirements, but then you actually get into the technical requirements at that point and then you flush them out. There's been a lot of situations I've been in where six months ago we planned everything out for the year. We planned, OK, this project's coming here. This project's coming here. Here's all the requirements. It's all flushed out. And then six months later, we have to do it all over again because the whole project has changed or we abandon all that work because nothing is going to we've gone a totally different direction. Or the other problem I've run into in some situations is where the group of people I'm working with or the project I'm working on has now changed hands three, four, five, six times. And the people that actually wrote the requirements or defined it aren't there anymore. So you have no one to go ask the questions of other than to try and find someone to go back and talk to the customer. And it can be very frustrating and very hard. So we have to make sure we ask those questions and flush them out. But it's just I'm curious on your point, you know, should we be defining tickets so far out or should we only really be refining tickets that we're going to pull into the current sprint or within a sprint or two? I think you did. I think there is a lot of value in doing it from the start, even like when you're because just about everybody does that. You start a project and you just like blush out a bunch of tickets. Like, here's a bunch of things we're going to need to do. And if you can, while you're in that initial design, visionary mode, however you want to look at it, when you're initially put some of that stuff together or even along the way, I think it is very particularly if you want agile to be its most valuable to your organization is when those ideas come up. I'm like, hey, here's a requirement. Flesh it out as best you can and put it into the backlog because what you want to do is cover, hey, remember we talked about this. And if you've got notes about it, it's going to help that much more. In particular, if you have a great idea, like this is a feature we need to have. And it's like, yeah, that's a great feature. And then you leave the company six months later, but they don't actually implement it until a year after that. At least your ticket has survived. And you've got enough details that either you can go to everybody, the rest of the group or whoever it is and say, hey, here's something we had. I don't really get it. Can we talk through it? And maybe it comes real or it may be something you look at. You're like, OK, we don't get it. We don't understand it. It doesn't make sense anymore. Just toss it because it's at the end of the day. That's the thing is you can just you can always throw a requirement out or you can just kick it down the road and say, you know what? We don't get it right now. We'll deal with it later. But when you're working it, yeah, you want it to be fresh. But I think that I think it is very useful and it is probably helpful to all of us to have something where we're like noting those little ideas as we go and making sure as best we can, we've got some details around it. So even ourselves, we can look at it six months from now and go, what the heck was I thinking? Oh, yeah, this is where it would do this. And then it would do that. We have that information and have tracked it so that we can help ourselves down the road as opposed to, OK, we're just going to we're going to just focus on the near the here and now and all that other stuff we're not going to bother with. And that's like even when it's a not small team, non agile kind of approach. I work with customers all the time where it's like, hey, this is, you know, version one or an MVP or something like that. And we have this ever growing section that is in the future, you know, future phase, next phase, whatever. And we just throw stuff in there because, like, oh, we do want to do this, but we really don't know what it's going to look like. We really don't want to spend time on it now because we may not get there, particularly in an MVP world. Maybe you go, you build that MVP, you get it out in front of customers. And you know, there's a lot of stuff you want to do to like really help them. But first, you want to make sure those customers exist and they're willing to pay for it. So there's there is a lot that goes into that. But the short answer, even though I know I've already blown that time out, the short answer is. Yes, you want to track every one of those things, put what you can into it at the time, but also be careful about getting too deep into the analysis side of it. Don't put implementation details in things like that instead. If it's something you know, that's going to go to the backlog, just give yourself enough information or for somebody else to understand where you're going with it so then they can find a way to take that that story again, it's that story, that why that feature and build it into whatever this thing looks like six months or a year down the road. Does that make sense? Yeah, exactly. And that was kind of where I was hoping you were going to go with that, because one of the things I've seen in some of the places I've worked is. Some of the project managers or the business will kind of backfill the backlog with potential projects that are coming down the line, and they are very highly, loosely defined tickets. And yeah, we flush them out, but then we don't touch them for six months. We talk about it again, but then we don't touch it for another month. What I've seen and this is I don't know if you've seen this too, but typically in most agile sprints that I've worked in in a good shop, you're always reviewing or re-reviewing what you're going to pull in for the next sprint or essentially the top five items in the top of your backlog are always fresh and have pretty much the mostly defined requirements that you need. Yes, if you go to the backlog and you pull it out. Take a second, read through the ticket, read through the requirements, make sure it still makes sense, make sure that what you're currently working on didn't change it. Typically, my rule of thumb, every ticket is wrong. It's just my rule of thumb. And that's the test for me. I look at something and I have to immediately know how is the user or how is this ticket supposed to work? How am I supposed to touch it? How am I supposed to click it? How you know, what do I do with this ticket? What's the outcome? You know, not necessarily a black box, but, you know, if I give it a A and B, I get C. OK, great. That tells me specifically if I'm doing this, I get this, which leads to, you know, how you test driven development these tickets. But if you think that way, when you're refining the tickets and you're looking at those requirements, no matter where you're at in this process, you should be OK. And if you do it first, you're going to spend less time, less headaches and not bang your head against the wall on tickets. Where essentially you're my computer doesn't work. Well, why doesn't it work? You know, nothing's in the description. But when the person or support finally calls a customer back and says, OK, what's the problem? And after spending one, two, three hours on the call with them, you find out, well, their computer doesn't work because they're in the middle of a blackout. Yeah, you've got to. Yeah, you've always got to pick a little bit outside of the box when you're when you're tracking some of those things now. But I think it is it's it is a that is a nice thing about test driven development and even having where it is useful for developers to have any kind of like QA testing kind of background, because it does help us to think through, OK, what are what are the potential inputs and what are the outputs based on those and what are the exceptions and what are the errors and what are the message and asking those kinds of questions? Because that's going to almost that's almost going to apply to everything you ever build and to some level. And I think just getting those questions often starts the conversation to get deeper into it. If it's a if it's a ticket, an issue or a problem, you're solving this at a bigger scale. There's going to be all these little ones are going to end up being that are going to grow out of that conversation. Slight segue, I guess, is that this has grown out of just a couple of very simple questions and conversations, but we're going to wrap this one up because, hey, we're going to try to respect your time as best we can. As always, shoot us some questions. If you have any info at developer.com, check out the site. Subscribe wherever you're you have podcasts that you're listening to. All the different things out there. We're out there somewhere. Go find developer or or building better developers, depending on. We use that because some of these things that are voice activated, they don't understand the word developer as well as they do billing better developers. That's why. Well, that's why we converted our tagline to the name at one point. That being said, go out there and have yourself a great day, a great week, and we will talk to you next time. And for the rest of you, thank you so much for hanging out. This has been a, you know, again, we're going down some rabbit holes and we've warned you that this would happen, that these are the kinds of conversations we have. And I think they're probably the conversations you have as well, is that, you know, sometimes we just start talking about problems and we have more problems. It's just like requirements. You have a requirement, you start talking about it, and now they have more requirements. And it starts to, you know, sort of snowball until you get to the point where you finally start hitting leaves at the end of all of those little, you know, branches that you've hit from off of all of your requirements. So I think we will wrap this one up. Well, thank you again for your time. Check us out. Subscribe. Say hi. Leave comments. All that good stuff, because that just helps us give better comment content and just better copy and such for you as well. So you guys as well go out there, have yourself a great time. And we will see you on our next episode as we're just going to continue cranking through on the podcast side, we are cranking through season 21 and we're just moving along those episodes. And then here we're just going to continue on the YouTube side. Continue to crank these things out. And periodically, I promise I know I mentioned it before, and I have not in a while put out some of the tutorials, but we will return to those. It's just been a little bit busy time and we're hoping to settle that bound a little bit and throw a couple of those little tutorials out. Again, if you have questions, comments or requests for tutorials, in particular, anything related to some of the stuff we've done in the last couple of years, my sequel, sequel in general, MariaDB, Python, Java, let us know. And we will see what we can do to help you out and throw a little tutorial together. Or we may have some fun exploring whatever that technology is as well. Go out and have a great time and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor 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.