Software Development Requirements - Staying True to Specifications

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are just cruising right along in season 21, I do believe it is, the Building Better Developers, Developer podcast. We are into a season where we're, this season we're really just going through some of the trials and tribulations that we have as developers. Myself, I hit them on a regular basis. My name is Rob Broadhead, one of the founders of Develop-a-Nour. I also am a founder of RB Consulting and go out and do software development all the time. And so that's where I run into some of these road bumps and such, one of which we're going to talk about today, which we're going to get into working specifically towards a requirement, like the filling to the letter in a sense, a requirement. But before I do that, one of the requirements is that I enter Michael to introduce himself on the other side. So go ahead and do that. Hey everyone, I'm Michael Melosh. I'm a co-founder of Develop-a-Nour and founder of Envision QA, where we help small healthcare small businesses build software and test their and improve their software through testing. So this is a, what I want to talk about this time is a, it actually is one of these things. It could be a very big topic, but we're going to narrow it down. And the idea originally we talked about, and those that are, because we do have a YouTube channel and you could watch us as well as listen to us. Those that were listening, watching beforehand though, that we, we got into this a little bit because it started at building stuff in silos. And this is, you know, when you're building software and you don't have access to the end customer, where your software is basically down to your writing code to requirements. It's not really a developer side. This is almost going backwards. It's not better developers. These are people that are just, and sometimes you have to do this because sometimes it's a fixed bid project or there's certain priorities and things like that. And maybe you don't know all of them, but they've listed them out effectively in the requirements they've given those to you and said, we need to do A, B, C, D. That's it. This is the challenge is because we usually are going to look at A, B, C, and D, and we're going to have a vision and it's not going to be the same as what they have. And as we get into it, we're going to see, because we're developers, we're going to see where we could do this or we could do that, or we could do this other thing. One of the most frustrating customers I've ever had was one that did not want us to change the code other than exactly the minimal changes to the code to do that task. And the code was atrocious and they knew it. It was like, there was all kinds of crap. It was like, it was hard to read because there'd be like, there'd be two lines of code and then there'd be five blanks line and then a line of code. And then there are a couple of blank lines and then a line of code. And then sometimes it'd be spread out and sometimes it'd all be jammed up. Just visually, it made you like your head spin a little bit. And they knew this, but they didn't want to change anything. And you may be in those situations. Maybe you're like DOD or something like that, where it's like, you don't know why you're doing it. All you know is that this is the requirement. And so those are the situations I want to talk about today is when you have a requirement or a hard list of requirements that like, this is a task you're supposed to do. This gets into something that's very near and dear to Michael's heart, because he mentions it probably every episode is look at the requirement and then make sure you clearly understand it. Do not be afraid to kick back questions, however you can do those to say, OK, you gave me these requirements, but here's some things that I need to have clarification on. You're not saying that their requirements are no good or that they can't be done or anything like that. What you're trying to do is you're trying to make sure that you understand the scope in the context. And then when you get and so that should give you the start is make sure you understand very clearly. If you can, don't be like sometimes the best way to do it is to essentially verbalize back whether it's through an email or whatever to say, OK, you sent me these requirements. And so you basically respond back with the design or something along those lines that say, OK, this is what I'm going to build. Or this is what I'm going to code. Or this is what I'm going to create. It's going to do this and this and this. And it may be that that's there or maybe that you're just adding to that ticket because you're saying, OK, let's make sure that I know what the criteria are to say that it's done. What are the validation criteria to say that this works? What are the things that this you know, what are the various inputs and what are the acceptable outputs? Walk through that data. This is where you have to get really detailed because what you don't want to do is anything that's beyond what's in that requirement, because you don't know. And I will tell a nice little story, too. This is a shared person we know. You don't know what effect that's going to have on something else. So if you go outside of that, if you color outside of the lines in a situation like this, it could be a problem. Now, I'm going to give you an example that is more than you probably are going to get into in this kind of situation, but an example of not going outside the lines. We had a situation, somebody that we were working with, a developer. The requirements were pretty simple. It was we need to we need to give a response. We need to have a pop up. I think it was a pop up window or it was a message bar kind of thing that says that when you save something or edit something that you get a response back that says, hey, you know, I saved it. You know, this has been saved. This is this was a successful transaction. That was essentially the gist of it. It's like, hey, on this application, we've got five places that we do these actions. We need to have some sort of it. We need to have a confirmation so the user knows that it occurred. Guy that did this developer was like young and go getter and wanted to show stuff off. So first off, he turned it into a little pop up window. Cool. OK, you want to do a pop up window instead of a status bar. That's all right. That's fine. That wasn't in the requirement. That still works. That shows them something. Now, the problem is starting with just that window is that now that means somebody may have to click to continue on and maybe they don't want to do that. So if you're thinking about that, don't do it unless there's something implied and or ask a question and say, hey, I'm thinking about doing this with your original design. Say this is what I'm going to do. Let's make sure that this conforms to the requirements. If it doesn't say, give me a pop up, if it just says show a status, then you just show a status on the screen in some way, form or fashion. Don't add the pop up. Error number one, error number two is his pop up was in text. It was like little blinky lights that nobody likes, blinky lights. They did in like 1970 when there was a first web page came out, when Al Gore created the first web page since then, nobody wants little blinking lights around their messages. So that was also an error because it's like you can do it, but that doesn't mean you should. The other thing he did, which is actually a really interesting little tweak that we need to consider along with the pop up box is that he had it fade away after five seconds is it would flash the text up and it would fade away and everything would go away. So if you turned away, if you hit save and you turned away and you look back, you may not see that message at all. Our boss read him the riot act over that stuff because he's like, I don't like these. I don't like this look. And you can't do that because people aren't going to be able to see it. And it, it totally blindsided him because he was going into a meeting thinking he was going to get a big pat on the back and or I don't know, kudos or raise or promoted to CEO or whatever it was. He thought it was all good. Our boss did not ripped him a new one. And it is because, and it's his fault and it's, it is his fault because he had requirements and he decided to cover out of the lines and that was not part of it. Now, if you're a designer, if you're something where they say, Hey, go make this work, we want you to build something that impresses us, then you may do some of that. But even then, even if you're not in a silo, think about what may impress those people or ask them about it or give them some options to make sure that they're or give them some options so that you're not putting something in front of them. That they end up not liking because you don't want to spend a lot of time building something that isn't going to work or isn't going to fit the requirements. So look at the requirements, be clear. And then if you have an itch to do anything that is not part of the requirement, it's like, it's, it's like the old, what would Jesus do? It's like, what would the requirement do? Look at the requirement and say, does that thing that you're building, does that exactly match the requirement? And if not, don't do it. Ask a question, see if this is needed or, or if you're trying to help them say, would it be helpful if we can do that? Cause sometimes you're going to clap back and say, no, sometimes they're going to go, Oh, I didn't think about that. Yes. Let's adjust the requirements. Your thoughts on that while I close windows that are being rained in on. Yeah. So the first thing that came to mind on that, I, I know I keep bringing this up, but it goes back to that, um, the swinging roller coaster cartoon that's on the internet for software development, where the initial request from the user is they want a tree swing and it goes from every concept of wooden planks swing, putting it on a tree, cutting the tree in half, building for a roller coaster, not supporting it, et cetera. Requirements are important, but the other thing that's interesting in this conversation is Rob mentioned is if you are doing this as a fixed bid or you're doing this as a contractor, or you are working in a silo for an organization, anything you do costs time, which costs you money. So if you have a requirement that really should take five minutes and you spend an hour because you do all this extra stuff that the customer didn't ask for. One, yes, you might impress them, but two, you just did a whole bunch of work that you're not going to get paid for. The other flip side of that is anything you work on, make sure you understand what it is that you're trying to do. As Rob mentioned, we had this friend that did the little pop-up window. Think about the user experience as well as the requirements is what you're going to do going to impact the end user in a positive way or in a way that meets the requirements because you could do something that is really cool, really neat within the scope of the requirements, but still not meet the need of the customer. So I want to, I do want to hit on that. One thing that Michael mentioned, because it really is, it goes back to these when we're not in a silo, when we get assignments, part of the thing that we can look at from the requirements is, which is very helpful for us as well, feedback and estimate. If they haven't given you an estimate, then feed something back of, hey, this is going to take an hour, two hours, a day, a week, whatever it's going to be, or look at and take into account what their estimate is. If they give you something and they say, okay, here's your work for the week, then you know that they're expecting it's going to take a week. That can help you figure out how much you're supposed to add in, even if it's not in a silo. And I have dealt with this a lot of times with people as a manager as well of developers is to say, okay, this is what you're going to do. I'm expecting it back today or in an hour. I don't expect, I expect you get these 10 things done today. So that should help somebody know or help you know if there's like, you know, it's like, this is your daily to do list. If you're stuck on, if it's got five items and you're stuck on the first one for seven hours, you're probably not going to get it all done unless those other things are super easy. So one, if there's something that seems like it's going to blow up, that it's like, that you're chasing that it's like, this seems way more complicated than I thought it was. Don't be afraid to feed that back and say, hey, this is, this is a concern. This is not where it's supposed to go. That's part of this part. Why agile is what it is when you do a daily stand up and say, hey, this was supposed to be, you know, two days of work, roughly. I'm into my, my whole first day and I'm not even nowhere started on this. Things like that is feed that back because it may be that either you've misunderstood the requirement or the people that are creating a requirement may not understand what that means. And particularly with a customer, this may be something like, oh, if it's going to take, you know, I thought it was just going to take you five minutes. If it's not going to take you five minutes, I don't need it. There's, you know, it allows people to properly prioritize. And it helps you to think through like, what is really expected out of this? If it's something where you've got like, you know, very strict requirements and it's, it's something where it's like, oh, that's 10 lines of code. If I do it a certain way, then it's like, okay. And you only have time to do those 10 lines of code. Then that's what you do. Now, obvious, obvious. Well, it's not obviously, but it should be included that you're going to have, you know, you're going to do some testing and some validation and stuff like that as well. So nothing gets done like that, at least not completely done. But that is a, that is a really important thing to think about is what is the, the scope and the expectations of what you're building as well, because you don't want to be in a situation where you run, especially these days with the, the mobile development kind of stuff we do with the remote development that we do, where we're out there somewhere, we get some requirements. If we go away for a week and come back and we're nowhere close to end, but they thought we were done with those requirements four days ago, then that's going to be a problem. So we want to make sure that we're clear also on the scope and the level of effort that's going to be involved with what we do. And with that also something we haven't really talked about here, you know, if you're in this silo environment, you might not be the only one that software you could be working on could have multiple different teams, multiple different silos working on this application. So your, potentially your changes could impact someone else or someone else's changes could impact you. So understanding the requirements and understanding how that interacts, not necessarily full big picture, but a bigger picture as the, to the why we're doing this does make sense. Unfortunately, in some situations you don't have the capability of asking that why you can only really get into the requirements as to, all right, what is within the scope of this ticket? What am I doing? You know, why is this needed? Not necessarily why is this application needed, but within the functionality that you're working on, you need to forcefully, not forcefully, but you need to at least understand and be forthcoming with the person who's requesting the changes that could be the project owner. That could be your boss. You know, it could be another developer. It could be a bug ticket that was reported, but make sure you understand what the issue is, what the requirements are. Are there any screenshots? Are there any scripts to kind of lay out how to test this? You know, is this a user interaction? Is this a webpage? Uh, is there any diagrams to kind of help you understand how it's all put together? And then from there, then you can give an estimate. Now, if you're new to this game, you're going to be wrong a lot. You're going to be behind the ball. So make sure you give yourself time, at least on the first few assignments to really understand what it is and how things work within the organization. As you build up your skills, you're going to be better at estimating those times. But you know, even a seasoned developers, you know, we can miss something because we don't have a requirement. This one hour change can now take us a week that because whoops, we need this third party API or we need this integration piece. Oh, that's not done yet. Well, we can't move forward. We can build something to, uh, you know, to stub that, but that still takes time. And that was time that was not considered in the initial requirements. And that's actually a good, the working as a team is part of that as well as because sometimes you're going to be given something and there is an expectation of when it's going to be delivered. And you may look at it and say, Hey, you know, I'm going to deliver it a little late, but I'm going to add so much extra stuff to it that it's going to be worth it. You don't have the, you may not have the ability to make that decision because what may happen is that your piece has to be done by that time because somebody else is waiting on it. And so if you delay, then it causes somebody else to be delayed and then somebody else to be delayed and you can throw a lot of stuff off schedule. If you start, you know, sort of going off on your own. So it's, it really is this topic really does cover the, it's almost like the reverse of building better developers. It's, it's being a better developer as a team player, but it's really when you're in situations and we all will hit those sometimes where it's like, we just need to be a coder. Yes. We want to build out, you know, we want to have all this knowledge and experience around the solutions we build, but sometimes it is, it is not that we're building something better. It's that they need us to build it faster because we can write that code quickly. We can do it simply. We can get there, get in and get out. And not be dawdling around. And it's not that they need our ability to write the coolest, most flowery, awesome solution. They need us to write one quick that works that we can verify and then move on. And so understand the context of what you're doing and that will help keep you out of trouble. Final thoughts on this? Yeah. The biggest thing I kind of want to leave as a takeaway is as you're working your tickets or if you're working these contracts independently or fixed bids on for customers, take the, take the requirements, take the job, take the ticket that you need to work on, understand what it is you're being asked to do. Make sure you stay within the focus of those requirements and what the user accepted criteria is. Don't go outside of the box of these situations. Don't add too many bells and whistles. Stay focused, work on the task at hand and get the work done within the timeframe. And we're trying to get our work done within our timeframe. So we're going to try to, we're going to wrap this one up in a respect to your time. As always, you can shoot us questions at info at developinord.com. You can check us out on Facebook. You can check us out on LinkedIn. You can check this out on YouTube. There's lots of places out there. wherever you, wherever you do podcasts, we're out there. And if not, let us know they should already be there, but if not, we'll add ourselves to the stack, as always looking for comments, questions, recommendations, requests, things like that, anything, any feedback we love to have, because this is as much for you as it is for us, actually more for you than it is for us, because we're just, you know, going through and, and sort of venting a little bit at the end of the day and trying to help out some others so that we can essentially be a cautionary tale as others so that our mistakes are not repeated, or at least, you know, that you're, you know, if you have already done those mistakes, you're like, Hey, I'm not the only one. These guys do it as well. And probably a lot of others. That being said, we'll let you get back to your day. So 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-Nord 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.