Detailed Notes
In this podcast transcript, Rob and Michael delve into the pivotal topic of defining requirements in software development. They emphasize the significance of clear and detailed requirements, underscoring the potential pitfalls of vague or incomplete requirements. Throughout the conversation, they provide insights, anecdotes, and practical strategies for navigating the complexities of requirement gathering and management. Let’s dive into the key points discussed by Rob and Michael.
The Importance of Clear Communication Rob and Michael stress the importance of clear communication in understanding and defining project requirements. They highlight the dangers of assumptions and ambiguity, advocating for a thorough exploration of the client’s needs and expectations. Drawing from their experience, they emphasize the need for developers to engage in detailed discussions with clients to ensure alignment on project goals and outcomes.
Understanding the End Goal A key topic we discuss is the necessity of understanding a project’s end goal before delving into its requirements. Rob and Michael illustrate the importance of clarifying objectives and envisioning the desired outcome using the tree swing example. This requires us to ask probing questions and seek clarity on client expectations. By doing so, developers can ensure that the final product meets the intended purpose.
Agile Approach to Requirement Management The conversation touches upon the agile approach to requirement management, emphasizing the iterative and adaptable nature of the process. Rob and Michael advocate for regular review and refinement of project requirements, especially in dynamic environments where priorities and circumstances may change over time. They underscore the value of maintaining a flexible backlog and continuously reassessing the relevance and feasibility of pending tasks.
Test-Driven Development and Quality Assurance The discussion expands to encompass the role of test-driven development (TDD) and quality assurance (QA) in requirement validation. Rob and Michael highlight the importance of thinking critically about user interactions and anticipated outcomes when refining project requirements. They advocate for a proactive approach to testing and validation, leveraging QA principles to uncover potential issues and ensure the robustness of the final product.
In conclusion, Rob and Michael emphasize the ongoing nature of requirement management and the importance of continuous improvement. They encourage developers to adopt a proactive mindset, actively engaging with clients and stakeholders to refine project requirements iteratively. By prioritizing clear communication, understanding the end goal, and embracing agile practices, developers can navigate the challenges of requirement gathering and deliver successful outcomes for their clients.
Final Thoughts on Defining Requirements As Rob and Michael wrap up their discussion, they invite listeners to engage with their podcast and provide feedback or topic suggestions at [email protected]. They reiterate their commitment to delivering valuable insights and practical advice for developers, underscoring the collaborative nature of their community. With a focus on continuous learning and improvement, they invite listeners to join them on their journey of building better developers.
By incorporating these key points and insights, developers can enhance their approach to requirement management and contribute to the success of their projects. Whether adopting agile methodologies, leveraging TDD principles, or prioritizing clear communication, a proactive and iterative approach to requirement definition is essential for delivering high-quality software solutions.
Additional Resources for Defining Requirements * Setting Realistic Expectations In Development - https://develpreneur.com/navigating-realistic-expectations-in-software-development/ * Creating Your Product Requirements - https://develpreneur.com/product-requirements/ * Changing Requirements – Welcome Them For Competitive Advantage - https://develpreneur.com/changing-requirements-welcome-them-for-competitive-advantage/
Transcript Text
[Music] all right what do you want to go what you mentioned something so Works being a pain so yeah so uh since we did just talked about branding and customer let's look at um defining requirements or understanding requirements because the biggest problem I've been struggling with this week especially is I've been given two tickets to do that literally are uh image size is incorrect on report nothing else in the ticket other ticket is getting an Excel uh styling exception with load testing that's it that's all that's on the ticket just the title nothing in the requirements what am I supposed to work with how do I Define the problem and that's been a huge struggle it's like you know you can tell someone to go dig a hole but if it's not in the right spot you'll tell them to dig it over here well eventually your yard ends up looking like swiss cheese right it's and the hole is nowhere near where you want it it's like that movie Holes it's like you just keep digging holes um but I think that would be a good topic how would we Define that or what do you think it should be I think that's that's not bad um I think it is something that it is definitely something that we've run into all the time and it's figuring out how to handle that um you the good news is that you've got that is actually a step I think ahead of a lot of people there's a lot of developers out there they get that ticket and they just like okay I'm going to go work on it and then you know a week later I see this in Sprints all the time it's like oh yeah I'm going to take these on and then they get to it and they read it and they're like well this doesn't have anything useful or they'll build it and it has because they'll see a title like yeah this is what I'm going to do and you're like wait a minute that's not at all what you know what it was what needed to be done and now you've wasted your time and you got to go back and sometimes it's it's you have to you know uncode stuff or basically recode entire sections pull stuff out lots of issues um so I think there I think that's the whole how do we deal with requirements and how do we go back and ask for more requirements uh it's I think it's a pretty good topic for us so if nothing else we'll give it a shot um I'm going to take 30 seconds I'm going to refill my water though those of you that are there play soliter for 30 seconds and for those of you watching the bonus content these kinds of questions that U I'm bringing up or these problems not only is it a problem where you might get the wrong solution architected but you may if you're paying contractors or you're paying people hourly you have to figure out the time and the cost that if you just give someone a ticket to do or just some baseline requirements it could cost you a lot of money to go have them build something if you don't have anything defined properly and so let's dive in well hello and welcome back we are continuous 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 um I think even already in this 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 and you need to be sure that you 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 a whether it's a ticket whether it's a 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 GNA invite uh just welcome you back Mike we've been here the whole time but uh throw this over to you you can introduce yourself a little bit and we will dive into our requirements discussion sure um I'm mikae milash I'm founder of Envision QA and co-founder of develop prur 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 and 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 and the funny thing I saying about this is we did a season way back um way back it's been a couple 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 building and the customer having that drawing out of them clearity on what they need because it is as we've mentioned way too often there's people are like hey I want to build Airbnb for you know pet houses or something like that whatever it is it's just so 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 that'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 just just look at Airbnb and then bake something like that it's like no that's you it's like Google just make something like Google it's like okay I can write a page where you're gonna you know 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 one recognize that and two talk to a customer about that and instead of the what's so off when 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 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 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 and you know 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 like there's so many challenges that can come from not having the requirements now I'm going to throw this to you Michael but and I'm going to come back and I do want to talk about what happens when that like when it's intentional that you don't almost and where you can go with that but uh first let's let's stick to the that requirement discussion that conversation so the way you laid it out is typ 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 um 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 things to kind of unpack there so one uh 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 you know what is it that they are expecting to come out of this change walk back from that then go to the requirements and say okay this is what the end user wants this kind of goes back to that tree swing uh model that's all over the web you know customer wants a tree swing so you go back and say okay so what is it that you want to do well okay 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 okay we need to put a uh swing in a tree well what kind of Swing you know is it a typical uh two ropes and a board is it a tire and uh or a string in a 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 or 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 isn't again isn't 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 yeah and I think that's why you that discussion around requirements even is and minimize assumptions is talk to people about what what is that you want done what is the and it really goes back to what is the problem that 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 okay that doesn't help me what doesn't work how did you get there what does working look like and 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 prob rolling your eyes because there are those places where you just get stuff the CEO comes in and it's like hey here 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 um 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 pm 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 threw 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 had a really like big on the M MVP Maybe by you know 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 so 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 okay 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 okay 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 was 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 had to be able to page through them quickly the page has to come up quickly and like all the time a 100,000 a millon 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 you 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 initi it's like okay we're just going to get it done we're going to make it work we're going to make it work and finally it's sort of like wait a minute back this up why do we need to present a 100,000 rows to a customer and it finally got to well we need to do is we need to get to the last page and have at the bottom of that page count 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 and 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 okay dig a hole over here oh wait that's I want the 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 you okay why are we digging this hole because we want to get to a well okay well let's first make sure that when we dig a hole we're going to actually hit something that's got water you 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 right Cod but as you get further into your career you are paid to be even if you're an employee like 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 Prov 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 uh more midlevel 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 um 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 these software approaches especially with agile where you go through the process of kind of pointing tickets ahead of time you review tickets uh in 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 how what is your take you know how would you handle the approach of taking this ticket that we already have and we have flush CH requirements but maybe there's been some additional changes and 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 point of agile and having uh backlogs and things things like that is because you you do you rroom you don't just like pull tickets when you're grooming you're actually reviewing tickets in 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 few times where you've got something 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 okay this doesn't make sometime 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 than that they're in their interactions those things will just disappear when those things are no longer needed but sometimes they 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 okay you're telling me that we need to do ab C and D cool okay 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 question it goes back to ask those questions and again then 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 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 agal approach where things are changing as you go now if you've built something you're more like a waterfall and it's 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 um like as a just in time kind of approach like I'm going to will 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 change 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 to the technical requirements at that point and then you flush them out there's been a lot of situations I've been in where 6 months ago we plan everything out for the year we plan okay 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 abandoned 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 it's just I'm curious on your point you know should we be defining tickets so far out 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 do I I think there's 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 of like hey here's a requirement flesh it out as best you can and put it in 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 you're like this is a feature we need to have and he'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 you know the rest of the group or how whoever it is and say hey here's something we we had I don't really get it can we talk through it and maybe it it comes real or it may be something you look at you're like okay 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 over 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 okay we're just gonna 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 that's like even when it's a non 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 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 you 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 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 uh business will kind of backfill the backlog with potential projects that are coming down the line and they are very highly um Loosely defined tickets and yeah we flush them out but then we don't touch them for 6 months we talk about it again but then oh 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 back log 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 just my rule fell it's the tester to me I look at something in and I have to immediately know how is the user or how is this uh 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 black box but you know if I give it a a and b i get C okay great that tells me specifically if I'm doing this I get this which leads to you know how you test uh 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 okay and if you do it first you're going to spend less time less headaches and not bang your head against the wall uh 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 uh or support finally calls a customer back says okay what's the problem uh and after spending 1 2 3 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 gota 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 down 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 to Think Through okay 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 a ticket an issue or you know a problem you're solving that's 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 uh as always shoot us some questions if you have any at info developer.com check out the site U subscribe wherever you're you have podcasts that you're listening to all of the different things out there we're out there somewhere go find develop andur or building better developers depending on uh we use that because some of these things that are voice activated they don't understand the word develop preneur as well as they do billing better developers that's why well that's why we converted our tagline to the 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 uh you know again we're going down some rabbit hole 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 requirements 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 I want 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 uh content and just you know 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 uh on the podcast side we are cranking through season 21 and uh we're just moving along those episodes and then here we're just going to continue on the the YouTube side continue to crank these things out and periodically I promise I know I've mentioned it before and I have not in a while put out some of the tutorials but we will return to those uh it's just been a a little bit busy time and we're hoping to settle that down 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 now couple of years my SQL SQL uh in general Maria DB python Java let us know and we will uh we'll 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 uh go out have yourself a great time and we will talk to you next [Music] time
Transcript Segments
[Music]
all right what do you want to go what
you mentioned something so Works being a
pain so yeah so uh since we did just
talked about branding
and
customer let's look
at um defining requirements or
understanding requirements because the
biggest problem I've been struggling
with this week especially is I've been
given two tickets to do that literally
are uh image size is incorrect on report
nothing else in the ticket other ticket
is getting an Excel uh styling exception
with load testing that's it that's all
that's on the ticket just the title
nothing in the requirements what am I
supposed to work with how do I Define
the
problem and that's been a huge struggle
it's like you know you can tell someone
to go dig a hole but if it's not in the
right spot you'll tell them to dig it
over here well eventually your yard ends
up looking like swiss cheese right it's
and the hole is nowhere near where you
want it it's like that movie Holes it's
like you just keep digging holes um but
I think that would be a good topic how
would we Define that or what do you
think it should be I think that's that's
not bad um I think it is something that
it is definitely something that we've
run into all the time and it's figuring
out how to handle that um you the good
news is that you've got that is actually
a step I think ahead of a lot of people
there's a lot of developers out there
they get that ticket and they just like
okay I'm going to go work on it and then
you know a week later I see this in
Sprints all the time it's like oh yeah
I'm going to take these on and then they
get to it and they read it and they're
like well this doesn't have anything
useful or they'll build it and it has
because they'll see a title like yeah
this is what I'm going to do and you're
like wait a minute that's not at all
what you know what it was what needed to
be
done and now you've wasted your time and
you got to go back and sometimes it's
it's you have to you know uncode stuff
or basically recode entire sections pull
stuff out lots of issues um so I think
there I think that's the
whole how do we deal with requirements
and how do we go back and ask for more
requirements uh it's I think it's a
pretty good topic for us so if nothing
else we'll give it a shot um I'm going
to take 30 seconds I'm going to refill
my water though those of you that are
there play soliter for 30 seconds
and for those of you watching the bonus
content these kinds of questions that U
I'm bringing up or these
problems not only is it a problem where
you might get the wrong solution
architected but you may if you're paying
contractors or you're paying people
hourly you have to figure out the time
and the cost that if you just give
someone a ticket to do or just some
baseline requirements it could cost you
a lot of money to go have them build
something if you don't have anything
defined
properly and
so let's dive in well hello and welcome
back we are continuous 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 um I think even already in
this 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 and you need to be sure that you
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 a whether it's a
ticket whether it's a 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 GNA invite uh just welcome you back
Mike we've been here the whole time but
uh throw this over to you you can
introduce yourself a little bit and we
will dive into our requirements
discussion sure um I'm mikae milash I'm
founder of Envision QA and co-founder of
develop prur 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 and
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 and the funny thing I
saying about this is we did a season way
back um way back it's been a couple
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 building and the customer having
that drawing out of them clearity on
what they need because it is as we've
mentioned way too often there's people
are like hey I want to build Airbnb for
you know pet houses or something like
that whatever it is it's just so 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 that'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 just just
look at Airbnb and then bake something
like that it's like no that's you it's
like Google just make something like
Google it's like okay I can write a page
where you're gonna you know 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 one
recognize that and two talk to a
customer about that and instead of the
what's so off when 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 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 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 and you know 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 like there's so
many challenges that can come from not
having the requirements now I'm going to
throw this to you Michael but and I'm
going to come back and I do want to talk
about what happens when that like when
it's intentional that you don't almost
and where you can go with that but uh
first let's let's stick to the that
requirement discussion that
conversation so the way you laid it out
is typ 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 um 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 things to kind of
unpack there so one uh 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 you know
what is it that they are expecting to
come out of this change walk back from
that then go to the requirements and say
okay this is what the end user wants
this kind of goes back to that tree
swing uh model that's all over the web
you know customer wants a tree swing so
you go back and say okay so what is it
that you want to do well okay 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 okay we need
to put a uh swing in a tree well what
kind of Swing you know is it a typical
uh two ropes and a board is it a tire
and uh or a string in a 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 or 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
isn't again isn't 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 yeah and I think
that's why you that discussion around
requirements even is and minimize
assumptions is talk to people about what
what is that you want done what is the
and it really goes back to what is the
problem that 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 okay that
doesn't help me what doesn't work how
did you get there what does working look
like and 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 prob rolling your
eyes because there are those places
where you just get stuff the CEO comes
in and it's like hey here 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 um 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 pm
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 threw 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 had a really like big
on the M MVP Maybe by you know 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 so 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 okay 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 okay 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 was 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 had to be able to page
through them quickly the page has to
come up quickly and like all the time a
100,000 a millon 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 you 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 initi it's like okay we're
just going to get it done we're going to
make it work we're going to make it work
and finally it's sort of like wait a
minute back this
up why do we need to present a 100,000
rows to a
customer and it finally got to well we
need to do is we need to get to the last
page and have at the bottom of that page
count 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 and 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 okay dig a hole over here oh
wait that's I want the 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 you okay why are we digging this
hole
because we want to get to a well okay
well let's first make sure that when we
dig a hole we're going to actually hit
something that's got water you 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 right Cod but as
you get further into your career you are
paid to be even if you're an employee
like 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 Prov
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 uh more
midlevel 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 um 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 these software approaches
especially with agile where you go
through the process of kind of pointing
tickets ahead of time you review tickets
uh in 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 how what is your take you
know how would you handle the approach
of taking this ticket that we already
have and we have flush CH requirements
but maybe there's been some additional
changes and 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 point of agile
and having uh backlogs and things things
like that is because you you do you
rroom you don't just like pull tickets
when you're grooming you're actually
reviewing tickets in 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 few times
where you've got something 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 okay this doesn't make
sometime 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 than that
they're in their interactions those
things will just disappear when those
things are no longer
needed but sometimes they 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 okay you're telling me that
we need to do ab C and D cool okay 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 question it
goes back to ask those questions and
again then 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 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 agal approach where things are
changing as you go now if you've built
something you're more like a waterfall
and it's 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 um like as a just in time kind
of approach like I'm going to will 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 change 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 to the technical requirements at
that point and then you flush them out
there's been a lot of situations I've
been in where 6 months ago we plan
everything out for the year we plan okay
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 abandoned 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 it's just I'm curious on your
point you know should we be defining
tickets so far out 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 do I
I think there's 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
of like hey here's a requirement flesh
it out as best you can and put it in
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
you're like this is a feature we need to
have and he'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 you know the
rest of the group or how whoever it is
and say hey here's something we we had I
don't really get it can we talk through
it and maybe it it comes real or it may
be something you look at you're like
okay 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 over 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 okay we're just
gonna 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
that's like even when it's a
non 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 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 you 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 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
uh business will kind of backfill the
backlog with
potential projects that are coming down
the line and they are very
highly um Loosely defined tickets and
yeah we flush them out but then we don't
touch them for 6 months we talk about it
again but then oh 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 back log 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 just my rule fell it's the
tester to me I look at something in and
I have to immediately know how is the
user or how is this uh 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 black box but you know if I
give it a a and b i get C okay great
that tells me specifically if I'm doing
this I get this which leads to you know
how you test uh 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 okay and if you do it first
you're going to spend less time less
headaches and not bang your head against
the wall uh 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 uh
or support finally calls a customer back
says okay what's the problem uh and
after spending 1 2 3 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 gota 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 down 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 to Think Through okay
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 a ticket an issue or
you know a problem you're solving that's
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
uh as always shoot us some questions if
you have any at info developer.com check
out the site U subscribe wherever you're
you have podcasts that you're listening
to all of the different things out there
we're out there somewhere go find
develop andur or building better
developers depending on uh we use that
because some of these things that are
voice activated they don't understand
the word develop preneur as well as they
do billing better developers that's why
well that's why we converted our tagline
to the 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 uh you know again we're going
down some rabbit hole 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
requirements 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 I want 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 uh content and just you know
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 uh on
the podcast side we are cranking through
season
21 and uh we're just moving along those
episodes and then here we're just going
to continue on the the YouTube side
continue to crank these things out and
periodically I promise I know I've
mentioned it before and I have not in a
while put out some of the tutorials but
we will return to those uh it's just
been a a little bit busy time and we're
hoping to settle that down 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 now couple of years my SQL SQL uh
in general Maria DB python Java let us
know and we will uh we'll 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 uh go out have
yourself a great time and we will talk
to you next
[Music]
time