Detailed Notes
Welcome back to the Building Better Developers Podcast, where we continue to explore the developer journey—from novice to expert—focusing on practical skills and mindset shifts that turn good developers into great ones. In this episode, we dive deep into a critical topic that affects developers at every stage of their careers: scope creep, requirements management, and defining what it means to be “done.”
Read More ... https://develpreneur.com/mastering-scope-creep-navigating-the-hidden-challenges-in-software-development
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources * Sprint Planning – Setting The Scope (https://develpreneur.com/sprint-planning-setting-the-scope/)
* A Positive Look At Scope Creep (https://develpreneur.com/a-positive-look-at-scope-creep/)
* The Importance of Properly Defining Requirements (https://develpreneur.com/the-importance-of-properly-defining-requirements/)
* Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects (https://develpreneur.com/getting-it-right-how-effective-requirements-gathering-leads-to-successful-software-projects/)
Transcript Text
[Music] howdy Everybody by fault we had a great conversation sorry you missed out on it I forgot to hit record not for the first time um so I think I wanted one of the things about uh all of you guys just to like clue you in we're talking about our topic for today and we're thinking we're going to go along the lines of like avoiding scope creep as a sort of a overall umbrella thing so okay now that you guys are caught up I can continue my conversation um I think part of it too is there's there's General scope creep and what is scope creep versus what is M requirements and I think this takes on a whole different world and I I want to talk a little bit about how you manage that in the agile world because this is also something that's very near and dear to my heart because I've just I've got a customer that I've just started working with that we've it's one of these it was a really tiny little thing it's like oh I just want this little thing and it's like cool but as we started talking about it it morphed into something much bigger and we ended up talking about a whole other application that I'm working on for him and it's basically it's like you working with his budget it's stuff where it's like okay well we're just going to keep you going along and we're just going to pay you periodically and we're just going to throw stuff on you know on the list and just keep doing stuff so it's in a sense it's an open-ended it's not like I'm just billing whatever I want to write I'm not writing Bank bank checks but it's an open-ended project right now and I've been in both of them are and I've been in a lot of those and one of the things is that even in an open-ended project or an agile project where you haven't really maybe necessarily defined the the goal line you still need to do it so that's where I think that may be even a part to or a followup to this is is the world of requirements and scope creep versus agile and some people I think feel that agile means that you could just keep skip you know scope creep forever but there is hopefully it's tied back to how agil does I don't want to spoil all the discussion but um hopefully that you still have a you know you're keeping a goal in mind and you're not just doing like Sprint after Sprint after Sprint after Sprint that I know there was a lot of stuff so thoughts on that as our topic so just to unpack that so are we looking to start at like through the agile process like with the open-ended project can I go through something like this or are we going to well and also touch on like the definition of done or what is done what our requirements kind of I know we've talked about requirements before but within this I think some of these top points will I know this will probably be a multiple Conversation Piece but I want to see how far we want to touch on those like the end pieces in this first conversation well I think let's see where we go if we start with the focus on which it is it's key things like you know requirements which defining done is part of scope creep you know it's like okay once you define done if go beyond that that's obviously scope creep but then there's other stuff within it um and I like the transition at agile I'm guessing that our conversation in this first one will just be this this episode will really just be not even touching agile just on a general sense of scope creep and requirements and defining done because I have a feeling we'll have them more than enough to throw into that and then we'll we'll follow that up because then we're sort of in that mode I think it'll be perfect to then talk to about uh the agile world and how that's a little people think it's different and it is but it also isn't and making sure that and it gets a little bit more into like avoiding uh runaway projects or death marches or stuff like that because it's agile and they're like well we didn't really Define requirements like no you do Define requirements it's just you are a little more flexible when they change does that make sense yeah yeah I follow with that okay let me move the camera stuff around so I'm looking more at you and my camera as opposed to other stuff and let me get this thing minimized out are we going to touch on ceremonies at all with agel or just keep it um because I think the ceremonies help if ceremonies are done right then you don't have some of that right so I guess that would be part of the I think I want to bring that up but definitely the in particular I think it's really it's it really is it's not necessarily the ceremonies as much as it really is the um the deployment at each Sprint at technically you know at each Sprint you should deploy working software so in theory that means that you don't really run out of you you could ideally cut it off at any point and say okay we're done we have working software you know we're out of we're out of money or we want to push this forward but that's not really the case there is there's always an MVP point and I think it's it's talking about that the ceremony should help that to some extent uh and it's I I think it's perfectly fine I think that's perfectly within uh boundaries of what we can talk about because I think those are some of the things we're talking about ways to tools to keep it straight to you know straighten stuff out so that it doesn't run off the rails okay works for me sounds good then let me move this around let me move that around and let me find my window again and sorry everybody you get to see how the sausage is made hello and welcome back we are continuing our season of just building better developers we are the building better developers podcast but now we're really talking about the developer Journey which is hopefully going to take you from a developer to a better developer whatever that happens to look like whether it's a you know starting at the beginning of your career and going to end of your career and it's dramatically different or whether it's something where you're just starting uh maybe you want to the beginning of the year where you at let's look you know a little bit talking about your journey through the year this episode I want to jump right into talking at least about the topic is um we're going to talk about scope creep we're going to talk about requirements we're going to talk about what is done what does that mean and that's something that often is a problem in projects allows things to get a little bit out of hand and then you get into this whole well you know cost overruns and you miss schedules but if you didn't know what you're building it's hard to really schedule that right as well before we do all of that I want to introduce myself I just want to leave that little like you know little hanging hanging thing there so that you come back after the introductions my name is Rob Broadhead I am one of the founders of building better developers developer or also a founder of RB Consulting where we go out and we do we basically make you we help you find ways to use technology better through integration simplification and automation is make that you know that big expensive car that you've built in your technology tur it into a a fine lean machine on the other side I'm also going to bring up what we did last couple times around is like what is a big a good thing and a bad thing that's happened since the last time we met that you want to throw on there and introduce yourself Michael hey everyone my name is Michael Mage I'm also one of the co-founders of developer ner building better developers and I'm also the founder of Envision QA we focus on highquality software and working with our customers to really establish what they really need their technology for is either better software uh better integration with existing software or building something very custom to their needs so good and bad so good uh making progress on my latest project we un peeling back the onion really getting down into some of the Neer details it's going really well uh thing's going a little you know not so well uh it end of the month I forgot to pay a bill so I had to unfortunately got hit with a you know late fee but you know it happens what about you all right so good stuff I got a lot of stuff I think this time is I'm just coming off a vacation got to go visit Aruba if you haven't been go it's awesome it's really a a great time we were exhausted by the time we got done with our vacation but that was a good one uh bad thing is uh I mean I guess here's a it's not that bad but I mean one of those projects where you need certain permissions and security and access in order to like get the project done and I'm just in this waiting period where it's like I keep you know it's like every day like hey I need you to give me this this and this access and they're just really slow to respond so it's like you know you're just drumming your fingers going okay can't really help you we we got this project we really want to get done we should be able to get it done quickly but not if you don't give us access to the proper stuff so that's my bad which actually it's their bad it's just my bad experience right now which goes sort of into requirements and scope creep now I think one of the big things about scope creep that I want to first talk about because I don't think I haven't really heard a lot of people think talk about it in this sense is that what really is scope cream because a lot of times what we have with projects is yes there are uh dates that are you know slip or you have uh you know change requests and stuff like that they come in and then so whatever the original project looked like that little box that somebody put it in and said it's going to cost x amount of money and Y amount of time has changed and sometimes it's it's often just called scope creep it's because oh well we added a feature we added a feature we added a feature but people don't always see it that way because sometimes they think that and it's whether it's it could be us as developers it could be them as our customer is that we added a feature and I'm air quoting for those who you know I don't know we need to figure out what that looks like in the audio world but for the video world you can see we added a feature in air quote and what we really did is we didn't really add a feature we found a requirement that was not that you know that was missed there was a gap in the requirements and this is where it gets interesting because depending on how the project is set up sometimes and actually quite often there will be different views of whether that was a problem or a flaw or something with the development or implementation team or whether it was something that is scope creep or something along those lines now in the very technical sense it is a new feature because it was not in the original requirements even if you thought it was in the original requirements it's a new feature because that was not part of the original estimate now it may seem like I'm splitting hairs a little bit here but it is something that I think changes the conversation and this is about being a better developer it changes a conversation about that particular change particularly when these things come in when you get deeper into implementation maybe you're already you know just barely on schedule or maybe you're already behind schedule and now you have a requirement that comes in that you realize that oh there was a we missed it whoever we is somebody missed that requirement and now that discussion is it was a requirement is it really a requirement is it really something that was requirement or is it something that we just sort of figured out as we went along that as that is a nice to have but because it was probably should have been you know it should have been caught technically should have been caught originally if you did everything right you would have got that in your requirements and then in that case it's like this is it is a requirement and now moves in the requirements we do have to adjust our schedules and that we have a reason for it it's not one anybody likes nobody's happy with that but it is a valid reason it's like this is it is what it is which is different from we're working Along on our project and hey we found out that we need to integrate with this different system or we don't like the way this worked when we initially talked about it we need this feature we need a reporting feature an export feature an import feature those those things that show up all the time when you get a customer in front of the application they actually start using it and if they don't have a really hard example to work from and this is even these days it happens more and more is what what happens is people realize what the technology can do and then they suddenly say oh wait because we can do this we really need to do that and it may be a very firm requirement but that's a different discussion and is how you approach it because it really is Now The Leverage is more on hey we're adding something to what we originally you know we're going to provide we're adding something because this is now it is it's a new feature versus you need to take a different approach when it's a oh we forgot to put that feature in so it's in a way not a feature and particularly if you have and this something that we were talking about a little bit before we hit record the idea of when you have a customer that is or customer representative somebody that's that that product owner where they have a lot of stuff in their head and they have all of these assumptions that are related to that there are going to be things where it's like oh you should know that this is how this process works or yes of course that process always has these five steps and you have to you explain that well to me it looked like it only had three steps it I didn't understand step four and five and so these are different conversations the good thing is is that you can avoid those if you ask those questions before you get into the implementation phase the bad this is one of those good and bad things the bad things is that you don't always know what you don't know now this goes a little bit back to I'll do a flashback as you can go into our how do you gather requirements discussion because that's really where it that's where the you know the value is that is where your gold is going to be is by asking the right questions and assume nothing when you're putting those requirements together don't assume that anything is there and constantly with stuff is there anything else is there something else how else does this work let's let me walk you through the process so for example if there's if I see three steps but there's five if I walk you through the process as a customer and say step one is this step two is this step three is that and say does that complete it hopefully they will say wait you missed step four and step five those are the kinds of questions now I think I've talked long enough to sort of set the stage on this and hopefully got that I also want to I wanted to pitch it to you as well to sort of talk about the defining what done is because I think that gets into your favorite way place to talk about testing and things like that I know it's subtle but I've picked that up so thoughts on all this yeah so I liked how you kind of laid out the two different ways where you kind of have scope like feature creep and then you have kind of like a bug creep where you there's actually something wrong with the system but you don't actually catch that until you actually get into the software uh and work with it uh interestingly I ran into that recently uh we found out that we had reports created one way we're switching to another uh data system in the back end and all of of a sudden the sort order of our reports is not the same so we uncovered a bug but they want apples to apples they want the old report or the new report to look like the old report which can't happen because the Sorting there's no way to we we would essentially have to create a bug to make it look like the old way but since we're actually pulling different data we can't really duplicate so it's kind of an apples and oranges issue which is something you do run into uh with features it's like oh the software we think works like this like Rob touched on but it is actually doing this so it's not an Apples to Apples it's an apples to oranges it's like it's not doing what we thought so we need to take a step back and understand what that requirement is Define it and make the software work the way it's expected to not necessarily the way we think it does that kind of gets you to that definition of done you know what is the end goal for the change the requirements whatever it is you're working on what does it mean to be done is it the feature has to be complete uh in agile you try to go through smaller Sprints so you always delivering code so you don't want these monolithic requirements or monolithic changes so how can you break it down into a way where we can roll things out in stages and still have different stages of done uh for instance like if you're building a big application that has security well you can build the login screen you can validate login but you don't necessarily need the entire application for that you can just focus on one section uh of the or one feature uh within that particular Sprint now circling back around to the definition of done so if you're working within the agile approach or you're working with these uh kind of situations one of the things that is interesting from a test driven approach a definition of done approach is you start with the end par what are you supposed to have at the end and like Rob said you shouldn't have any questions about this this should be very straightforward if this then this then this if there's an else with a possible splitting of scenarios that aren't defined you can't write that code that is unknown requirements and therefore you potentially could run into a situation where you're almost to the end oh we need this oh we need this so now you run into feature creep or requirements creep for missing requirements the one thing we rob didn't touch on is the other side of things so as developers uh especially front-end developers we will take a way of implementing something that like display a table and we will build the table but we don't like the way it looks so we'll add some colors to it we'll add some features while some bells and M that is scope creep that is not even feature creep it it's not necessary you don't do that but if you do that guess what your timelines get blown out of proportion and you don't meet the deadline so you've added scope creep to an application that wasn't necessary so you've made code changes that weren't required in the requirements they weren't in the definition of done so you now essentially blown your timeline to do something that you thought was cool but not what the customer wanted or wasn't expected so I've run into that I've done it myself especially in your early years as a developer you want to show off you want to show your skills so you are going to make that mistake and it's not necessarily a bad one but it is one that has impact it has a negative impact on your timelines so well the feature may look good it may be something the customer absolutely hates and therefore you get a bad reputation from the end user so it kind of goes back to that old adage the customer is always right but the customer is always right if and only if they give you the requirements that they need for the feature that you're building if they leave something out you're going to miss your deadline you're G to not be able to build them what they want so before I pass it back to you one of the things I would State and we talk about this in the requirements discussion is as you're going through the process and we'll get into this with agile more but through the process of agile you have different stages where you get the requirements for the next Sprint and you're supposed to go through and do a backlog refinement look at the requirements flush them out if you are not doing that you are going to be in a lot of trouble because you don't know if that ticket has all the requirements it needs it does may not have what the def definition of done is it may be missing oh hey you need to integrate with this particular software so before you can even write the uh changes you need to get access like Rob's running into getting access for one of the projects he's running into these are things that have impact that if you really look at the tickets or the requirements first you should be able to identify that at the beginning now sometimes something going to get missed you may be deing with Legacy software where no one in the company knows how the old stuff works anymore you're trying to rebuild it or you're trying to maintain it and it's going to be a hot mess you're going to run into situations where you will run into scope creep feature creep and missing requirements but in those situations before you even begin you need to set the expectation that this is how we perceive it working we're ready wrting the definition of done and the requirements on this however we are going to add within scope that this may not be what it's expected and at that point we're going to have to either create another ticket or we're going to need to go back and reanalyze the requirements so you do have checkpoints especially with agile to protect yourself but you need to make sure that you utilize them and not just go head long and assume that everything that the customer gives you or that the tickets have is what you need to do the job what are your that's actually there's a really good uh Junior versus middle versus senior level developer thing right in the midst of that which I've I've noticed and it does make a huge difference is when you get a task whether it's however it's done whether you've pulled a ticket off of because it's part of the Sprint and you're working in an agile mode or whether it's something that you've been assigned by your your boss your manager or whatever one of the first things we should always do is some level of design even if we're given a design and and all of these you know most of the pieces as a developer even as a coder there's some level of design there's some level of this is how I'm going to get this task completed a lot of times and this is where I say that when I usually a junior developer is just going to get it they're just going to start running in it they're going to like okay I'm going to start cranking code you learn a little further on you get more depending on where you're at in your soft mat software maturity level will say somewhere along the lines you realize that you've got to think about this a little bit before you do it and as you get further on you realize that you really need to think about it as you really need to it's not just as we've talked about a little bit before it's not just coding the happy path but it is how am I going to solve this problem and hopefully they gave us all the needs as far as like how am I going to solve this problem with the uh we'll call the proper data the happy path what are the places where there could be exceptions what is what does that look like when there's an exception how am I supposed to handle those what am I supposed to what are the uh constraints on values and all of those things that are factors that go into how you implement the solution so if you sit down and the first thing you do is you look at it and you say okay I'm going to sort of like sketch out in some way form or fash however tool you use it a design for what I'm doing that is often going to right away start to Bubble Up those questions that Michael's referred to where you're going to look at stuff as like wait I don't know what this is I don't know how this is supposed to work this is a a flaw in the requirements this is something that is not fleshed out enough this is something where there's a gap there's something you ask questions that is part of it because if you this goes back to what I said earlier if you assume you're like oh well I can assume all of this like you can but you may build something that actually does not fit the solution now hopefully the requirements include all the things that you need to know about done what does done look like you know what is it what is proper input what's proper output what are all the different ways it can handle invalid input and how is it supposed to do that if you've got all of that awesome but if you don't that's going to be your safety net basically regardless of whether it's agile or anything else when you're given that task sit down sketch it out somewhere that is going to highlight where there may be gaps I'll throw it back to you before we wrap this one up yeah so to kind of add on top of that so especially for some of the Junior and uh you know early beginner developers one of the other issues you can run into if you just jump in and code and I've seen this a lot is copying and pasting of code you may have a feature somewhere else that you think meets the requirements so you grab that you throw that in and you say you're done if you don't test it to the requirements that copy code could bite you in the ass so take the time look at the requirements even if you make the change make sure that it functions to the definition of done don't just assume always make sure that it works as expected I will follow that that is an excellent point uh it's a little bit of a I'm I feel bad that I did not bring that up because it's a little bit of a sore point I have in some cases most importantly what Michael just said in the context of chat GPT or any AI piece I don't know how many times I've seen code that has been pulled from you know before it used to be back in my day we had to write it all ourselves but then at some point there was Google and there was all these other places you can get code where it was just lifted and put in it's like boom this solves the problem no it does not necessarily solve the problem most importantly if you get it through one of these AI tools test it test it test it I don't know how many times I have found stuff and I use I use those tools to some extent and the to some extent is that every time I do it I'm going to go walk through everything to make sure that it actually does what I need it to do and if it doesn't then I'll adjust it accordingly but n times out of 10 I don't think I it is very rare for me to just be able to get that code plug it in it's like boom we're off and running almost every time it's not solving exactly the same problem so I have to make some adjustments so this is that being a better developer better developer does not mean you just slamming code in and you're getting it done faster it means you're building good code or at the very least you're solving the problem there and then as you get to be a better developer you're going to have the right habits to write better code from the start if not part of of it is you have you know some sort of a technology you know back U backlog of stuff where you're going to go back and do your Tech debt and go clean that stuff up but you don't clean it up it's not throw the coat in there and then clean it up even though it's horribly broken it's make it work and then you can come back and clean it up and make sure that it's like you know uses all of your prop follows all your proper standards and things like that that being said we got started here but we are not done we teased a little bit the whole idea of agile and how that's a little bit different and it is and that's we're going to talk about next episode so we don't you already know what's coming so hold your breath but not too long because it does take a while before these come out and then we will come back and we're going to continue really jumping right into this whole how do you deal with done and not having scope creep or scope Stampede as it often becomes or the world famous Death March when you're in an agile world because that can and often has happened and how do you set expectations but I've given you enough you can give me an email at info developer.com you can check us out on developer.com you can enter contact form we've got to contact us throw your suggestions your comments your favorite things that we've covered the things we need to cover more the things we need to cover less if we need to cover our faces in the videos that's fine as well I mean we get that we're not the prettiest people but we're here for you so let us know what you want let us know how we can help because we are also getting close to the end of the season and we're g to figure out what our next season is going to be just like we sort of figure out our episodes sometimes right as we go I think we hav't figured out this season at the beginning of the first episode we're like hey this is what the season's goingon to be because sometimes we do that because technology is everywhere and goes all over the place that being said you can go all over the place but come back here next time around go out there and have yourself a great day a great week and we will talk to you next time bonus material we don't want to we don't want to get into the agile yet so there's any bonus that you wanted to touch on here yeah so to Tech on to the copy code in the AI and copying code from the web look at your tools we've talked about Tools in previous uh discussions we've got good blogs on the site but especially if you're using Code generated AI these days if you ask it to write your unit test for you make sure you have something like sonar Q double cheing your code coverage to make sure that your tests are actually covering the code I've seen so many times where like chat GPT generates a valid test but it only covers one of 10 use cases so you think you're covered but you're not so you don't want to be like that one company that shut down the world with Microsoft by only running unit tests that were stale do your due diligence make sure you've got everything in place to check that you your code does meet the definition of done I think that is plenty of bonus material because then I'm sure I'm going to be running off at the mouth next time around so thank you so much for hanging out with us we will be back and you know what the next topic is but we'll probably do a little Preamble talk about that before we get into it and we'll just be back here next time as always give us whatever feedback you can you can leave us comments you can do likes you can do I don't know if there's dislikes or whatever it is but just like feedback is great however you give us feedback we enjoy that because we want to know how to be better as a podcast we're building better podcasting in our own little world along with us becoming Developers for yourselves thank you so much for your time and hanging out with us and we will see you next time [Music]
Transcript Segments
[Music]
howdy Everybody by fault we had a great
conversation sorry you missed out on it
I forgot to hit record not for the first
time
um so I think I wanted one of the things
about uh all of you guys just to like
clue you in we're talking about our
topic for today and we're thinking we're
going to go along the lines of like
avoiding scope creep as a sort of a
overall umbrella thing so okay now that
you guys are caught up I can continue my
conversation um I think part of it too
is there's there's General scope creep
and what is scope creep versus what is M
requirements and I think this takes on a
whole different world and I I want to
talk a little bit about how you manage
that in the agile world because this is
also something that's very near and dear
to my heart because I've just I've got a
customer that I've just started working
with that we've it's one of these it was
a really tiny little thing it's like oh
I just want this little thing and it's
like cool but as we started talking
about it it morphed into something much
bigger and we ended up talking about a
whole other application that I'm working
on for him and it's basically it's like
you working with his budget it's stuff
where it's like okay well we're just
going to keep you going along and we're
just going to pay you periodically and
we're just going to throw stuff on you
know on the list and just keep doing
stuff so it's in a sense it's an
open-ended it's not like I'm just
billing whatever I want to write I'm not
writing Bank bank checks but it's an
open-ended project right now and I've
been in both of them are and I've been
in a lot of those and one of the things
is that even in an open-ended project or
an agile project where you haven't
really maybe necessarily defined the the
goal line you still need to do it so
that's where I think that may be even a
part to or a followup to this is is the
world of requirements and scope creep
versus agile and some people I think
feel that agile means that you could
just keep skip you know scope creep
forever but there is hopefully it's tied
back to how agil does I don't want to
spoil all the discussion but um
hopefully that you still have a you know
you're keeping a goal in mind and you're
not just doing like Sprint after Sprint
after Sprint after Sprint that I know
there was a lot of stuff so thoughts on
that as our topic so just to unpack that
so are we looking to start at like
through the agile process like with the
open-ended project can I go through
something like this or are we going
to well and also touch on like the
definition of done or what is done what
our requirements kind of I know we've
talked about requirements before but
within this I think some of these top
points will I know this will probably be
a multiple Conversation Piece but I want
to see how far we want to touch on those
like the end pieces in this first
conversation well I think let's see
where we go if we start with the focus
on which it is it's key things like you
know requirements which defining done is
part of scope creep you know it's like
okay once you define done if go beyond
that that's obviously scope creep but
then there's other stuff within it um
and I like the transition at agile I'm
guessing that our conversation in this
first one will just be this this episode
will really just
be not even touching agile just on a
general sense of scope creep and
requirements and defining done because I
have a feeling we'll have them more than
enough to throw into that and then we'll
we'll follow that up because then we're
sort of in that mode I think it'll be
perfect to then talk to about uh the
agile world and how that's a
little people think it's different and
it is but it also isn't and making sure
that and it gets a little bit more into
like
avoiding uh runaway projects or death
marches or stuff like that because it's
agile and they're like well we didn't
really Define requirements like no you
do Define requirements it's just you are
a little more flexible when they change
does that make sense yeah yeah I follow
with that okay let me move the camera
stuff around so I'm looking more at you
and my camera as opposed to other stuff
and let me get this thing minimized out
are we going to touch on ceremonies at
all with agel or just keep it um because
I think the ceremonies help if
ceremonies are done right then you don't
have some of that right so I guess that
would be part of the I think I want to
bring that up but definitely the in
particular I think it's really it's it
really is it's not necessarily the
ceremonies as much as it really is the
um the deployment
at each Sprint at technically you know
at each Sprint you should deploy working
software so in theory that means that
you don't really run out of you you
could ideally cut it off at any point
and say okay we're done we have working
software you know we're out of we're out
of money or we want to push this forward
but that's not really the case there is
there's always an MVP point and I think
it's it's talking about that the
ceremony should help that to some extent
uh and it's I I think it's perfectly
fine I think that's perfectly within uh
boundaries of what we can talk about
because I think those are some of the
things we're talking about ways to tools
to keep it straight to you know
straighten stuff out so that it doesn't
run off the rails okay works for me
sounds good then let me move this around
let me move that
around and let me find my window again
and sorry everybody you get to see how
the sausage is made hello and welcome
back we are continuing our season of
just building better developers we are
the building better developers podcast
but now we're really talking about the
developer Journey which is hopefully
going to take you from a developer to a
better developer whatever that happens
to look like whether it's a you know
starting at the beginning of your career
and going to end of your career and it's
dramatically different or whether it's
something where you're just starting uh
maybe you want to the beginning of the
year where you at let's look you know a
little bit talking about your journey
through the year this episode I want to
jump right into talking at least about
the
topic is um we're going to talk about
scope creep we're going to talk about
requirements we're going to talk about
what is done what does that mean and
that's something that often is a problem
in projects allows things to get a
little bit out of hand and then you get
into this whole well you know cost
overruns and you miss schedules but if
you didn't know what you're building
it's hard to really schedule that right
as well before we do all of that I want
to introduce myself I just want to leave
that little like you know little hanging
hanging thing there so that you come
back after the introductions my name is
Rob Broadhead I am one of the founders
of building better developers developer
or also a founder of RB Consulting where
we go out and we do we basically make
you we help you find ways to use
technology better through integration
simplification and automation is make
that you know that big expensive car
that you've built in your technology tur
it into a a fine lean
machine on the other side I'm also going
to bring up what we did last couple
times around is like what is a big a
good thing and a bad thing that's
happened since the last time we met that
you want to throw on there and introduce
yourself
Michael hey everyone my name is Michael
Mage I'm also one of the co-founders of
developer ner building better developers
and I'm also the founder of Envision QA
we focus on highquality software and
working with our customers to really
establish what they really need their
technology for is either better software
uh better integration with existing
software or building something very
custom to their needs so good and bad so
good uh making progress on my latest
project we un peeling back the onion
really getting down into some of the
Neer details it's going really well uh
thing's going a little you know not so
well uh it end of the month I forgot to
pay a bill so I had to unfortunately got
hit with a you know late fee but you
know it happens what about you all right
so good stuff I got a lot of stuff I
think this time is I'm just coming off a
vacation got to go visit Aruba if you
haven't been go it's awesome it's really
a a great time we were exhausted by the
time we got done with our vacation but
that was a good one uh bad thing is uh I
mean I guess here's a it's not that bad
but I mean one of those projects where
you need certain permissions and
security and access in order to like get
the project done and I'm just in this
waiting period where it's like I keep
you know it's like every day like hey I
need you to give me this this and this
access and they're just really slow to
respond so it's like you know you're
just drumming your fingers going okay
can't really help you we we got this
project we really want to get done we
should be able to get it done quickly
but not if you don't give us access to
the proper stuff so that's my bad which
actually it's their bad it's just my bad
experience right
now which goes sort of into requirements
and scope
creep now I think one of the big things
about scope creep that I want to
first talk about because I don't think I
haven't really heard a lot of people
think talk about it in this sense is
that what really is scope cream because
a lot of times what we have with
projects is yes there are uh dates that
are you know slip or you have uh you
know change requests and stuff like that
they come in and then so whatever the
original project looked like that little
box that somebody put it in and said
it's going to cost x amount of money and
Y amount of time has
changed and sometimes it's it's often
just called scope creep it's because oh
well we added a feature we added a
feature we added a
feature but people don't always see it
that way because sometimes they think
that and it's whether it's it could be
us as developers it could be them as our
customer is that we added a feature and
I'm air quoting for those who you know I
don't know we need to figure out what
that looks like in the audio world but
for the video world you can see we added
a feature in air quote and what we
really did is we didn't really add a
feature we found a requirement that was
not that you know that was missed there
was a gap in the requirements and this
is where it gets interesting because
depending on how the project is set up
sometimes and actually quite often there
will be different views of whether that
was a problem or a flaw or something
with the development or implementation
team or whether it was something that is
scope creep or something along those
lines now in the very technical sense it
is a new feature because it was not in
the original requirements even if you
thought it was in the original
requirements it's a new feature because
that was not part of the original
estimate now it may seem like I'm
splitting hairs a little bit here but it
is something that I think changes the
conversation and this is about being a
better developer it changes a
conversation
about that particular change
particularly when these things come in
when you get deeper into implementation
maybe you're already you know just
barely on schedule or maybe you're
already behind schedule and now you have
a requirement that comes in that you
realize that oh there was a we missed it
whoever we is somebody missed that
requirement and now that discussion is
it was a requirement is it really a
requirement is it really something that
was requirement or is it something that
we just sort of figured out as we went
along that as that is a nice to have but
because it was probably should have been
you know it should have been caught
technically should have been caught
originally if you did everything right
you would have got that in your
requirements and then in that case it's
like this is it is a requirement and now
moves in the requirements we do have to
adjust our schedules and that we have a
reason for it it's not one anybody likes
nobody's happy with that but it is a
valid reason it's like this is it is
what it is which is different from we're
working Along on our project and hey we
found out that we need to integrate with
this different system or we don't like
the way this worked when we initially
talked about it we need this feature we
need a reporting feature an export
feature an import feature those those
things that show up all the time when
you get a customer in front of the
application they actually start using it
and if they don't have a really hard
example to work
from and this is even these days it
happens more and more is what what
happens is people realize what the
technology can do and then they suddenly
say oh wait because we can do this we
really need to do that and it may be a
very firm requirement but that's a
different discussion and is how you
approach it because it really is Now The
Leverage is more on hey we're adding
something to what we originally you know
we're going to provide we're adding
something because this is now it is it's
a new feature versus you need to take a
different approach when it's a oh we
forgot to put that feature in so it's in
a way not a feature and particularly if
you have and this something that we were
talking about a little bit before we hit
record the idea of when you have a
customer that is or customer
representative somebody that's that that
product owner where they have a lot of
stuff in their head and they have all of
these assumptions that are related to
that there are going to be things where
it's like oh you should know that this
is how this process works or yes of
course that process always has these
five steps and you have to you explain
that well to me it looked like it only
had three steps it I didn't understand
step four and five and so these are
different
conversations the good thing is is that
you can avoid those if you ask those
questions before you get into the
implementation phase the bad this is one
of those good and bad things the bad
things is that you don't always know
what you don't know now this goes a
little bit back to I'll do a flashback
as you can go into our how do you gather
requirements discussion because that's
really where it that's where the you
know the value is that is where your
gold is going to be is by asking the
right questions and assume nothing when
you're putting those requirements
together don't assume that anything is
there and constantly with stuff is there
anything else is there something else
how else does this work let's let me
walk you through the process so for
example if there's if I see three steps
but there's five if I walk you through
the process as a customer and say step
one is this step two is this step three
is that and say does that complete it
hopefully they will say wait you missed
step four and step five those are the
kinds of questions now I think I've
talked long enough to sort of set the
stage on this and hopefully got that I
also want to I wanted to pitch it to you
as well to sort of talk about the
defining what done is because I think
that gets into your favorite way place
to talk about testing and things like
that I know it's subtle but I've picked
that up so thoughts on all
this yeah
so I liked how you kind of laid out the
two different ways where you kind of
have scope like feature creep and then
you have kind of like a bug creep where
you there's actually something wrong
with the system but you don't actually
catch that until you actually get into
the software uh and work with it uh
interestingly I ran into that recently
uh we found out that we had reports
created one way we're switching to
another uh data system in the back end
and all of of a sudden the sort order of
our reports is not the same so we
uncovered a bug but they want apples to
apples they want the old report or the
new report to look like the old report
which can't happen because the Sorting
there's no way to we we would
essentially have to create a bug to make
it look like the old way but since we're
actually pulling different data we can't
really duplicate so it's kind of an
apples and oranges issue which is
something you do run into uh with
features it's like oh the software we
think works like this like Rob touched
on but it is actually doing this so it's
not an Apples to Apples it's an apples
to oranges it's like it's not doing what
we thought so we need to take a step
back and understand what that
requirement is Define it and make the
software work the way it's expected to
not necessarily the way we think it
does that kind of gets you to that
definition of done you know
what is the end goal for the change the
requirements whatever it is you're
working on what does it mean to be done
is it the feature has to be complete uh
in agile you try to go through smaller
Sprints so you always delivering code so
you don't want these monolithic
requirements or monolithic changes so
how can you break it down into a way
where we can roll things out in stages
and still have different stages of done
uh for instance like if you're building
a big application that has security well
you can build the login screen you can
validate login but you don't necessarily
need the entire application for that you
can just focus on one section uh of the
or one feature uh within that particular
Sprint now circling back around to the
definition of done so if you're working
within the agile approach or you're
working with these uh kind of situations
one of the things that is interesting
from a test driven approach a definition
of done approach is you start with the
end par what are you supposed to have at
the end and like Rob said you shouldn't
have any questions about this this
should be very straightforward if this
then this then this if there's an else
with a possible splitting of scenarios
that aren't defined you can't write that
code that is unknown requirements and
therefore you potentially could run into
a situation where you're almost to the
end oh we need this oh we need this so
now you run into feature creep or
requirements creep for missing
requirements the one thing we rob didn't
touch on is the other side of things so
as developers uh especially front-end
developers we will take a way of
implementing something that like display
a table and we will build the table but
we don't like the way it looks so we'll
add some colors to it we'll add some
features while some bells and M that is
scope creep that is not even feature
creep it it's not necessary you don't do
that but if you do that guess what your
timelines get blown out of proportion
and you don't meet the deadline so
you've added scope creep to an
application that wasn't necessary so
you've made code changes that weren't
required in the requirements they
weren't in the definition of done so you
now essentially blown your timeline to
do something that you thought was cool
but not what the customer wanted or
wasn't expected so I've run into that
I've done it myself especially in your
early years as a developer you want to
show off you want to show your skills so
you are going to make that
mistake and it's not necessarily a bad
one but it is one that has impact it has
a negative impact on your timelines so
well the feature may look good it may be
something the customer absolutely hates
and therefore you get a bad reputation
from the end user
so it kind of goes back to that old
adage the customer is always right but
the customer is always right if and only
if they give you the requirements that
they need for the feature that you're
building if they leave something
out you're going to miss your deadline
you're G to not be able to build them
what they
want so before I pass it back to you one
of the things I would State and we talk
about this in the requirements
discussion
is as you're going through the process
and we'll get into this with agile more
but through the process of agile you
have different stages where you get the
requirements for the next Sprint and
you're supposed to go through and do a
backlog refinement look at the
requirements flush them out if you are
not doing that you are going to be in a
lot of trouble because you don't know if
that ticket has all the requirements it
needs it does may not have what the def
definition of done is it may be missing
oh hey you need to integrate with this
particular software so before you can
even write the uh changes you need to
get access like Rob's running into
getting access for one of the projects
he's running into these are things that
have impact that if you really look at
the tickets or the requirements first
you should be able to identify that at
the beginning now sometimes something
going to get missed you may be deing
with Legacy software where no one in the
company knows how the old stuff works
anymore you're trying to rebuild it or
you're trying to maintain it and it's
going to be a hot mess you're going to
run into situations where you will run
into scope creep feature creep and
missing requirements but in those
situations before you even begin you
need to set the expectation that this is
how we perceive it working we're ready
wrting the definition of done and the
requirements on this however we are
going to add within scope that this may
not be what it's expected and at that
point we're going to have to either
create another ticket or we're going to
need to go back and reanalyze the
requirements so you do have checkpoints
especially with agile to protect
yourself but you need to make sure that
you utilize them and not just go head
long and assume that everything that the
customer gives you or that the tickets
have is what you need to do the job what
are your that's actually there's a
really
good uh Junior versus middle versus
senior level developer thing right in
the midst of that which I've I've
noticed and it does make a huge
difference is when you get a task
whether it's however it's done whether
you've pulled a ticket off of because
it's part of the Sprint and you're
working in an agile mode or whether it's
something that you've been assigned by
your your boss your manager or
whatever one of the first things we
should always
do is some level of design even if we're
given a design and and all of these you
know most of the pieces as a developer
even as a coder there's some level of
design there's some level of this is how
I'm going to get this task
completed a lot of times and this is
where I say that when I usually a junior
developer is just going to get it
they're just going to start running in
it they're going to like okay I'm going
to start cranking code you learn a
little further on you get more depending
on where you're at in your soft mat
software maturity level will say
somewhere along the lines you realize
that you've got to think about this a
little bit before you do it and as you
get further on you realize that you
really need to think about it as you
really need to it's not just as we've
talked about a little bit before it's
not just coding the happy path but it is
how am I going to solve this problem and
hopefully they gave us all the needs as
far as like how am I going to solve this
problem with the uh we'll call the
proper data the happy path what are the
places where there could be exceptions
what is what does that look like when
there's an exception how am I supposed
to handle those what am I supposed to
what are the uh constraints on values
and all of those things that are factors
that go into how you implement the
solution so if you sit down and the
first thing you do is you look at it and
you say okay I'm going to sort of like
sketch out in some way form or fash
however tool you use it a design for
what I'm doing that is often going to
right away start to Bubble Up those
questions that Michael's referred to
where you're going to look at stuff as
like wait I don't know what this is I
don't know how this is supposed to work
this is a a flaw in the requirements
this is something that is
not fleshed out enough this is something
where there's a gap there's something
you ask questions that is part of it
because if you this goes back to what I
said earlier if you assume you're like
oh well I can assume all of this like
you can but you may build something that
actually does not fit the solution now
hopefully the requirements include all
the things that you need to know about
done what does done look like you know
what is it what is proper input what's
proper output what are all the different
ways it can handle invalid input and how
is it supposed to do that if you've got
all of that awesome but if you don't
that's going to be your safety net
basically regardless of whether it's
agile or anything else when you're given
that task sit down sketch it out
somewhere that is going to highlight
where there may be gaps I'll throw it
back to you before we wrap this one up
yeah
so to kind of add on top of that so
especially for some of the Junior and uh
you know early beginner developers one
of the other issues you can run into if
you just jump in and code and I've seen
this a lot is copying and pasting of
code you may have a feature somewhere
else that you think meets the
requirements so you grab that you throw
that in and you say you're done if you
don't test it to the requirements that
copy code could bite you in the ass so
take the time look at the requirements
even if you make the change make sure
that it functions to the definition of
done don't just assume always make sure
that it works as expected
I will follow that that is an excellent
point uh it's a little bit of a I'm I
feel bad that I did not bring that up
because it's a little bit of a sore
point I have in some cases most
importantly what Michael just said in
the context of chat GPT or any AI piece
I don't know how many times I've seen
code that has been pulled from you know
before it used to be back in my day we
had to write it all ourselves but then
at some point there was Google and there
was all these other places you can get
code where it was just lifted and put in
it's like boom this solves the problem
no it does not necessarily solve the
problem most
importantly if you get it through one of
these AI tools test it test it test it I
don't know how many times I have found
stuff and I use I use those tools to
some extent and the to some extent is
that every time I do it I'm going to go
walk through everything to make sure
that it actually does what I need it to
do and if it doesn't then I'll adjust it
accordingly but n times out of 10 I
don't think I it is very rare for me to
just be able to get that code plug it in
it's like boom we're off and running
almost every time it's not solving
exactly the same problem so I have to
make some adjustments so this is that
being a better developer better
developer does not mean you just
slamming code in and you're getting it
done faster it means you're building
good code or at the very least you're
solving the problem there and then as
you get to be a better developer you're
going to have the right habits to write
better code from the start if not part
of of it is you have you know some sort
of a technology you know back U backlog
of stuff where you're going to go back
and do your Tech debt and go clean that
stuff up but you don't clean it up it's
not throw the coat in there and then
clean it up even though it's horribly
broken it's make it work and then you
can come back and clean it up and make
sure that it's like you know uses all of
your prop follows all your proper
standards and things like that that
being
said we got started here but we are not
done we teased a little bit the whole
idea of agile and how that's a little
bit different and it is and that's we're
going to talk about next episode so we
don't you already know what's coming so
hold your breath but not too long
because it does take a while before
these come out and then we will come
back and we're going to continue really
jumping right into this whole how do you
deal with done and not having scope
creep or scope Stampede as it often
becomes or the world famous Death March
when you're in an agile world because
that can and often has happened and how
do you set expectations but I've given
you enough you can give me an email at
info developer.com you can check us out
on developer.com you can enter contact
form we've got to contact us throw your
suggestions your comments your favorite
things that we've covered the things we
need to cover more the things we need to
cover less if we need to cover our faces
in the videos that's fine as well I mean
we get that we're not the prettiest
people but we're here for you so let us
know what you want let us know how we
can help because we are also getting
close to the end of the season and we're
g to figure out what our next season is
going to be just like we sort of figure
out our episodes sometimes right as we
go I think we hav't figured out this
season at the beginning of the first
episode we're like hey this is what the
season's goingon to be because sometimes
we do that because technology is
everywhere and goes all over the place
that being said you can go all over the
place but come back here next time
around go out there and have yourself a
great day a great week and we will talk
to you next
time bonus material we don't want to we
don't want to get into the agile yet so
there's any bonus that you wanted to
touch on here yeah so to Tech on to the
copy code in the AI and copying code
from the web look at your tools we've
talked about Tools in previous uh
discussions we've got good blogs on the
site but
especially if you're using Code
generated AI these days if you ask it to
write your unit test for you make sure
you have something like sonar Q double
cheing your code coverage to make sure
that your tests are actually covering
the code I've seen so many times where
like chat GPT generates a valid test but
it only covers one of 10 use cases so
you think you're covered but you're not
so you don't want to be like that one
company that shut down the world with
Microsoft by only running unit tests
that were
stale do your due diligence make sure
you've got everything in place to check
that you your code does meet the
definition of
done I think that is plenty of bonus
material because then I'm sure I'm going
to be running off at the mouth next time
around so thank you so much for hanging
out with us we will be back and you know
what the next topic is but we'll
probably do a little Preamble talk about
that before we get into it and we'll
just be back here next time as always
give us whatever feedback you can you
can leave us comments you can do likes
you can do I don't know if there's
dislikes or whatever it is but just like
feedback is great however you give us
feedback we enjoy that because we want
to know how to be better as a podcast
we're building better podcasting in our
own little world along with us becoming
Developers for yourselves thank you so
much for your time and hanging out with
us and we will see you next time
[Music]