Detailed Notes
In the world of software development, the difference between a successful project and a frustrating one often boils down to one critical factor: effective requirements gathering. When teams fully understand what they need to build, how it functions, and what the end-user expects, they are much more likely to deliver a product that meets or exceeds expectations. However, when requirements are vague or misunderstood, the project can quickly veer off course. This blog explores the importance of gathering precise requirements, setting clear expectations, and establishing a solid foundation for successful software projects.
Read More... https://develpreneur.com/getting-it-right-how-effective-requirements-gathering-leads-to-successful-software-projects
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
* Software Development Requirements: Staying True to Specifications (https://develpreneur.com/software-development-requirements-staying-true-to-specifications/)
* The Importance of Properly Defining Requirements (https://develpreneur.com/the-importance-of-properly-defining-requirements/)
* Changing Requirements – Welcome Them For Competitive Advantage (https://develpreneur.com/changing-requirements-welcome-them-for-competitive-advantage/)
* Creating Use Cases and Gathering Requirements (https://develpreneur.com/creating-use-cases-and-gathering-requirements/)
Transcript Text
[Music] hey I just hit record so we are live oh hey there was my mic um so today gosh there's like because we were just in the Preamble venting a little bit and I just did an article so one of the things I've thought about is doing a and I wonder have we' done this before where it's the the famous I just want to do X but as y like I just want to do Uber for dog food or hey I just need a site that is PayPal but it's you know only for Euros or something like that you know you get these people that it's like and I I really think it's we've talked about it from a I want to build a business that is you know eBay but it's for blah it's for furniture um but I think there's also one that I'm seeing and this actually sort of follows up our prior one where we talk about these situations where people come in with a uh system that is been there they know it it's theirs and it's outdated and now they need to upgrade it they need to update it and walking through that because I've walked I've seen a couple different customers approaches to that and I think you've I mean you've got one right now is that everybody's there are a couple different ways to look at it some people are like I love what we have I need it exactly the same way and then some people I hate what I have I have no idea but it's got to be better and then there's those that are like I hate what I and here's where I need to go with it but even in all of those cases there's there are a lot of assumptions in there and that's where I was thinking about is as a developer it really gets in this really gets into like and I think there's one we had thrown out there sort of it's like Gathering requirements Gathering requirements in the situations where one where there are some there but they're not written and then those kinds of conversations and how do we handle them and how do we tackle those kinds of things little more advanced in the developer Journey but I think it is uh it's one of those things that even early on there are good questions around requirements actually I think it fits with the developer Journey especially kind of where we're at because we've kind of touched on different things especially from starting out you know going from coder to developer to next um and we've talked about like working in teams and tools and things like that and we have touched on documentation but this is kind of one that kind of fits between customer expectations documentation and what you're going to build so now we're at that point where all right now you know how to write code you've worked on a couple different projects you're maybe out on your own you're you're you know you're building apps but now you're getting into now I'm servicing customers now I'm getting into working on more complex systems how do I you know how do I tackle that and I I think that's a good one it kind of and I've seen the the job postings like you just explained where it's like oh hey I want someone to go copy Twitter for me for 50 bucks it on like freelance and some of those it's like they have zero expectation for what it takes to go into code they just see the big bucks from what comes out of it or what they perceive to come out um it's kind of one of those where this is kind of a level setting for both the developer and the customer and I think if we kind of tackle it from that it will fit perfectly within this journey of this season well I like how you laid it out so I think yeah so I think we'll give that a shot and and see where it goes I think that's a good little intro and hello and welcome back we are here cruising through the developer journey I am Ron Broadhead one of the founders of develop also known known as building better developers also a founder of RB Consulting where we simplify integrate and automate and do our best to just take the nightmare that technology can become and turn it into a nice pretty little fuzz ball that you can use to help your business get done faster better sharper and allow you to sleep at night on the other side is someone who actually never sleeps at night or close to it Michael and I'm going to let you introduce yourself hey everyone my name is Michael Mage I'm also one of the co-founders of building better developers developer and I'm also the founder of Invision QA if you are a small to midsize business or a small Healthcare clinician or doctor's office we help you identify what systems you have in place what software uh that you're using and we also build custom softwares so if the tools you have aren't quite working for you we can build you what you need which actually kind of goes into the conversation we're going to have today yeah that's a nice little dove tapil into we're going to talk a little bit about it's it's sort of about requirements and and expectation setting and level setting and some things like that and as we were talking about in the pre-show that you can go watch out on YouTube it's a little bit idea of like first you first you're working at just writing code and then you're sort of becoming a developer so you're developing Solutions now you're getting into the point where you're you're not maybe you've built your own Solutions but now it's working with other people to figure out what they need what is their problem and how do you figure out how to solve their problem and give them a solution that works now there's a couple ways that we step into this this this topic I want to focus on which is uh a disconnect we'll call it one is it's the we've talked about this before we've s thrown it out there and Michael just example like somebody sees I want to create uh Twitter and I want to create something just like Twitter but I'm going to call it flitter and their you know their budget is 50 bucks it's like okay you have no idea aide what's involved it's not just like changing three lines of text and then giving it over to you you have no idea what's involved in the solution behind there this can also happen with customers and this is really where I want to focus little more because instead of building new stuff which is more likely to I think normally draw Us in as far as like Gathering requirements and walking through that process with the customer even if they have done some of that work beforehand because sometimes you will get you know a fairly solid list of requirements but then you're still going to you you're going through them you're going to have questions and so it it naturally progresses when you're dealing with an existing system that a customer has there's a two or three different ways that people look at it one I think I'll go into three there's the one where it's an old system that we love it works great we really don't want to you know it's not broke don't fix it kind of thing but we do need to upgrade it because the technology is being sunsetted or something like that then you have the people that are on the other end that are like we've got this thing it was a piece of crap it doesn't work we hate it we've been trying to get off of it forever and it's now the technology is sunsetting and we've just we've waited too long and now we need to and we want to build something completely different and then you have somewhere I guess we'll say in between where people have something that we have something not really what we want we've learned something lessons from it and we want to build something better now the good thing is in all three of those cases you when you come in not only building better developers we want to build better Solutions so whether they love their solution or they hate it or somewhere in between we want to talk to them about that solution we want to understand in this situation what is it you have today what are the processes how does it work how does it you know how is it successful how is it failured where your paying points it's really talking before you get anywhere into what we're going to build for you or where we're going to go with it let's really understand what you have now that can be a challenge because sometimes you're going to get stuff where they say well just go work on the application or here's you know rarely do you get here's full documentation but they'll be like here's a user's guide and you'll have an application with 100 screens that's got a you know two-page user guide or something like that and there's all points in between the thing is this goes back to something we talk about a lot it's the why why is that there why how is it used and it is so easy for even somebody we'll just say like I could be an example of where you've done this a bunch but you don't push on the I need to understand the business side of it and that can run you into problems because now what you're doing is you're making assumptions you're going to assume that what the customer tells you is exactly what's going on and while sometimes that's correct sometimes it's not particularly with systems there's a lot of times that we have gone in and done assessments and and evaluations and things like that and you get into it and you find that maybe you start let's say you start with the CEO and maybe they're they like built this from the ground up so they talk like they know everything and then you start talking to their team and you find some people that are like oh we have this other thing we use it's not because the CEO is you know not smart or it's just like people grow and and move and they do these other things and there's stuff that's not on their radar and you'll find those kinds of things and and even within their systems they may use it all the time and it's not and they think that this thing is just you know a smooth integration and then you find out that oh no behind the scenes it's actually like multiple Integrations they've got Al all these licenses they've got to have maybe two or three vendors involved and don't even get me started if you've had multiple teams of Developers individuals come in over the years because this goes back to some of our other conversations is it always looks like it was written by 50 different people even if it was three and so it gets really difficult to understand what's there because you can't look at the code unless it's super super simp you can't look at the code and know what it does if it's like add a number subtract a number okay now we're like then maybe you can look at the code even a basic crud app where you're just insert update delete records do some listing there's probably some validations in there and if you can't crawl through all if you don't crawl through all the code and make sure you got every little piece of code reviewed which is very timec consuming you're probably going to miss something and even if you do you're probably going to miss something because it's you know sometimes hundreds of thousands of lines of code so what do we do this goes to we come back to the fundamentals one we want to make sure that we are setting expectations now sometimes your expectations are going to have assumptions and you're going to have to step up when those assumptions are proved incorrect so for example if you step into an a project and they say we really don't have to do anything but copy these files from A to B and you're good okay assuming that it's going to take us x amount of time here's what we're going to do cool and then you find out well you can't just copy those there's some other things that are going on and there's some stuff over here that you got to look at and oh these things can't just be copied they've actually got to be Rewritten at those points you're like hold up stop we made an assumption and now we have to reset because now the project has changed what we walked into as we got further into it we realized that's not it and you're going to feel bad sometimes you're GNA have customers you're going to say hey why didn't you tell us that up front and you can say we didn't spend the time walking through all this code up front and if they wanted you to or if they want you to walk through all the code upfront then you want to make sure you've got some sort of an agreement or something so you're getting paid because you don't want to be in a situation where you spend weeks of time crawling through code putting together a nice requirements document and they're like ah sorry we're not going to do that and they walk off and use your stuff somewhere else the other part of this is the the real fundamental when you're looking at that application however you're looking at it even if you can't see the code when you're looking at the screens in that ask questions how did I get here what is this what does this data do where does this data go where is it used don't be afraid to just be like a two-year-old ask questions ask questions ask questions because that is how you're going to get the requirements and that's how you're going to find the things that are in their head particularly when they've used this application day in and day out for years there is so much knowledge that just they know and they just know it like they breathe but they to tell them give me that information you have to find a way to extract it you've got to write that ask the right question and you're going to end up having to ask a lot of questions because you won't know that question until you ask it so that's like a big long-winded approach and I'm going to toss over Michael and sort of get your your feedback on those and what are your thoughts when you run into these situations so let me start with a little bit of current events which kind of ties into this nicely so the current debacle that kind of shut down the US recently uh with an operating system failure it has been discovered that the company that was working on the software only tested their code using unit tests and unit tests are a form of requirements or tests built on the requirements to test the code a certain way as you're going through these projects if you're not collecting the requirements if you're not filling in those assumptions and updating your tests if all you're doing is making code changes running your test good shipping the software if you never do end to- end testing or any other validation testing to make sure that the system works as the user wants it you're going to break things so that's what happened which literally shut down a lot of systems within the country flipping back to that so as developers as we are working our way through software through new software integrating software working with a customer I am very anal about how I go about Gathering requirements because I have worked on multiple sides of the fence uh Rob has too a little bit but I've decided at one point I need to step out of development I wanted to be a tester I wanted to learn more about integration testing automation testing and see how I could apply the test driven development approach as a developer working on systems working with customers especially today since a lot of our work is done virtually we do a lot of work through the computer so it's very important to sit down with your end user or your customer and have them walk through the system with you do they have a login screen well if you have a login screen you have to ask yourself okay sure they takes a username and password but if you have some type of authentication they probably are not thinking in their minds that they probably have role based permissions or role-based uh interfaces where certain things happen in the application for certain people so this person may come in they're an admin they see everything in the system it's like cool this is how it works you build it that way and you roll it out and next thing you know hey um why can my customers access payroll um that shouldn't happen well you didn't show it to me that way so there's a lot of nuances with software that your end user your customer may not know so you're GNA want to talk to more than one person if you can about the system Rob mentioned writing up software requirements well sometimes you don't have the time sometimes you're pitched with hey we have this so you're going to make a bid or an initial bid or statement of work to say hey I can do it for X based on these assumptions however once you get in there very quickly try to find out if those assumptions are right don't wait too long if you can catch this within the first few days you usually have a little more bandwidth to go back and say hey we need to re-evaluate this contract what you pitched us does not match what we have however sometimes what you are told is fairly close to what you have within the system so you get in there okay things are going along as expected but like Rob said there might be assumptions or things that aren't seen from the end users perspective so as you're walking through an application even even if it's for the first time at the start of the contract walk through the user stories so what is a user story a user story is how a person interacts with the system what is the person doing on the keyboard what are their objectives you know I am coming to this page to do what what is my expectation from the application and what is the results so you're kind of thinking that blackbox testing information in information out but there's stuff that happens there that you have to break down so that you can actually write the code or fix the code or even understand what the code is doing behind the scenes so this kind of gets into that whole white box gray box testing development you have to look at things to gather this information and as you're doing this you're going to find that there are what are called happy path or for simple user stories for the basic implementations of the system most companies and most users have that but what they don't have is all the other things that are required to keep that happy path working like for instance with the login can the user name is it an email can is uh is it just numeric characters is it alpha numeric does it have to have special characters you know what conditions are required just for the username password same thing now if I'm logging into the system okay sure I can have a user account but what happens if I you know what happens if I try to log in three times does my account get locked does my account expire if I log in am I logged in Forever do I never have to log in again so just in that scenario alone I've already thrown out half a dozen scenarios that you need to think about and account for just for a login page for from the user's perspective hey I log into this application it lets me in if I put in the right password it doesn't let me in if I have the an incorrect user name or password from the end user that's what they see but from a developer we have to think about all those nitty-gritty details to make sure that the application works now I've kind of really dragged down on that path but it's one of those where attention to detail from a developer mindset it's not just about hey I have this feature no I need to understand how this feature works and works with the system as a whole not just that piece because it could work for me my unit test could pass but when you get to the end user I click here to get to this page whoops I just broke that that doesn't work but my page works but I've have now broken other implementations or other features within the system so you have to be careful with what you do but you also um have to think about these things from the end user's perspective while thinking about it as a developer so that way even if you don't do the requirements you have an idea to start building the software and if you do it from a test driven perspective you're writing all these tests first all these scenarios first and then you're building the code that the test will test so essentially if you're doing a login okay I have a username I have a password variable I pass it into this uh method I should get logged in or I should be rejected because it's not a valid password and then you essentially write those methods and then change your test to call that method from the hardcoded pass and test your code so that's kind of my box on this part of it uh Rob where some more are your thoughts I want to go I do want to say that when we talk about setting expectations and the and the whole like I don't know how many times I've seen stuff where it's like it's really a simple project you just have to take this thing and move it from point A to pointb I think if you struggle with getting your customer to understand the complexities involved I think the login is one of the most perfect examples to work with because it is literally dozens if not more of decisions that are made with a login and it is it's stuff like Michael talked about it's like what's your it's and some people think oh well it's how long how complicated is your password and then what is your you know is your login a name or is it an email address well this is where you go a lot deeper is there's things like okay what characters aren't allowed what characters aren't allowed for the name is are you going to have a display name that this user is going to be seeing elsewhere in the system is that their login and if so that's a security risk because now somebody at least knows what their login is and so you don't necessarily want that which is the same thing if it's their email address then somebody could guess their email address and use that as a login do you want to do that what happens if they forget their password what happens if you want to add maybe initially do or maybe later you want to add some multiactor authentication how does that work do you have the ability which is a lot of systems now have are you going to need the ability that is the for admins to log in as a user which goes a little bit to what Michael said where you now get to see the system as that user and not as you as a super user maybe see a much different system and it goes on and on it's like well do you log out what happens when you log out when you log in do you where do you go do you go to your homepage does your homepage change depending on what your role is and then it just there's so many things that can be involved there that alone people are usually like well we just need to log in and we need to log out okay let's go into explore that and by the time you've asked about the 10th question you say okay that's just the login we haven't gotten anywhere else that's why this is complicated that's why when we say we're trusting you we're trusting you with a lot if we're just going to say we trust you that your login system currently works fine we're trusting that you've answered all those questions and that they all make sense and this goes to a little bit to the unit testing which is Michael's idea is like okay let's say that same login and your login Works flawlessly but let's say that for example you don't store a display name or you store personal information for first and last name and it's a system where that shouldn't be displayed anywhere but everybody else somewhere down the line says well I just need a name so I'm just going to take first last name put it together and then that's that's how I address them well yeah those both work fine but when you put it into the system you're not following a story and I think that's probably where we're going to go next but not right now because we have gotten a little long on this one as we sometimes do and we are going to wrap this one up and go work on our requirements because that's what we do as always we can gather requirements from you by sending us emails at info developer.com you can check us out on developer nerd.com we've got a form there you can sign up you can leave us comments you can see tons and tons of com of content you can check us out at school. developer.com and see some of the like the really short less than an hour up to multi-day tutorials and and lessons and classes that we've got there subscribe wherever you subscribe to podcast and then three other places as well just cuz and you can get this uh we're going to drop we drop this twice a week out on the YouTube channel you get to see that twice a week if you're listening you get bonus material although you can I mean you can always color us out so you don't have to watch us but there's extra content as well out on the YouTube channel that's the developer or Channel out on YouTube you can go find us there plus pass Mastermind Mentor sessions and things like that as well so there's tons of content and now I'm going to take a deep breath and go grab a glass of water or something like that but for you go out there and have yourself a great day a great week and we will talk to you next time bonus material so it's funny as you were talking about the school uh site um because remember I've got that entire course out there on software requirement documentation and software test documentation so um that that's a good source and we got lots of content on the site about testing and writing uh documentation things of that nature one thing I would add to this particular conversation though is when you go into your conversations with your customer well we are giving them the power because they are essentially The Keeper of the keys they are The Keeper of the knowledge of what the system is doing or what they want it to do we have to make the assumption that one we know nothing we have assumptions but we know nothing about what they have or what they want unless we've been working on so if you're coming in fresh assume nothing assume everything's wrong two take anything someone gives you for a requirement and pick the hell out of it if there's anything that is a what if or an if then in the requirements and there is no distinction of what the then is it's not a requirement it needs to go back and be clearly defined because your requirements should be one task or essentially how the feature Works should be feature complete it should be if this then this if this then this there should not be if if I do this I might get this oh wait we might also get this or wait we might also get this if you get into the code or you get into the requirement and you read this and then you say well wait what about this what about this what about if there's any questions at that point you need to stop and redefine that requirement uh because if you start writing code to that you may throw it all away because it could be completely wrong so you have to be very careful about that for your time because if you do that the customer may not pay you again to fix it you may have to eat that cost because you made the Assumption went off and did that when the customer really wanted something else done so you have to be careful as you go out and start building these applications Rob one followup to that and then we'll we'll wrap this one up is I do want to talk a little about along with setting expectations and requirements in that is making sure that there is along with all this what the easiest thing to say is what done is is there's a lot of times that we get to a point we do this with our personal applications I know customers do this all the time as you get towards the end and then it's like oh can you do this can you do that can you make this little change can you do that little change hey can we just do this can we do that and it may be and it is frustratingly simple sometimes it's like yes I can change those three letters and change that label or yes I can change a number and it's going to change the color of that button or whatever it happens to be a lot of times they very simple changes the moral of this story is there's no such thing as a simple change if you touch the code there is potential particularly as you get later into a project there is potential that you are going to have a typo that you're going to have something that didn't go right that you're going to actually you know that these days you got to watch out AI stuff will insert code on on you I don't know how many times that has frustrated me I've had to go turn things off because you go and it complete autocomplete something incorrectly for you and if you're not paying attention you're like wait I would have never typed that what was what kind of idiot oh the AI idiot that's the one so don't ever assume it like everything this gets into like the whole idea of like this is why with scrum you use points instead of hours the minimum the minimum thing you do assume it's going to take half hour an hour something like that maybe more than that use that to focus them on what gets us to done and the extra stuff we will get there we can add that later we'll do that in another release what we're going to do in another release is we'll step into another topic but for now I think we've gone long enough and we will get on our way as always check us out at all of the race places leave us some comments shoot us an email at info develop or.com and we will check you guys out next time around [Music]
Transcript Segments
[Music]
hey I just hit record so we are live oh
hey there was my mic um so today gosh
there's like because we were just in the
Preamble venting a little bit and I just
did an article so one of the things I've
thought about is doing
a and I wonder have we' done this before
where it's the the famous I just want to
do X but as y like I just want to do
Uber for dog food or hey I just need a
site that is PayPal but it's you know
only for Euros or something like that
you know you get these people that it's
like and I I really think it's we've
talked about it from a I want to build a
business that is you know eBay but it's
for blah it's for
furniture um but I think there's also
one that I'm seeing and this actually
sort of follows up our prior one where
we talk about these situations where
people come in with a uh system that is
been there they know it it's theirs and
it's outdated
and now they need to upgrade it they
need to update it and walking through
that because I've walked I've seen a
couple different customers approaches to
that and I think you've I mean you've
got one right now is that
everybody's there are a couple different
ways to look at it some people are like
I love what we have I need it exactly
the same way and then some people I hate
what I have I have no idea but it's got
to be better and then there's those that
are like I hate what I
and here's where I need to go with it
but even in all of those cases there's
there are a lot of assumptions in there
and that's where I was thinking about is
as a developer it really gets in this
really gets into like and I think
there's one we had thrown out there sort
of it's like Gathering requirements
Gathering requirements in the situations
where one where there are some there but
they're not written and then those kinds
of conversations and how do we handle
them and how do we tackle those kinds of
things little more advanced in the
developer Journey but I think it is uh
it's one of those things that even early
on there are good questions around
requirements actually I think it fits
with the developer Journey especially
kind of where we're at
because we've kind of touched on
different things especially from
starting out you know going from coder
to developer to next
um and we've talked about like working
in teams and tools and things like that
and we have touched on
documentation but this is kind of one
that kind of fits between customer
expectations documentation and what
you're going to build so now we're at
that point where all right now you know
how to write code you've worked on a
couple different
projects you're maybe out on your own
you're you're you know you're building
apps but now you're getting into now I'm
servicing customers now I'm getting into
working on more complex systems how do I
you know how do I tackle that and I I
think that's a good one it kind of and
I've seen the the job postings like you
just explained where it's like oh hey I
want someone to go copy Twitter for me
for 50 bucks it on like freelance and
some of those it's like they have zero
expectation for what it takes to go into
code they just see the big bucks from
what comes out of it or what they
perceive to come out
um it's kind of one of those where this
is kind of a level setting for both the
developer and the customer and I think
if we kind of tackle it from that it
will fit perfectly within this journey
of this season well I like how you laid
it out so I think yeah so I think we'll
give that a shot and and see where it
goes I think that's a good little intro
and hello and welcome back we are here
cruising through the developer journey I
am Ron Broadhead one of the founders of
develop also known known as building
better developers also a founder of RB
Consulting where we simplify integrate
and automate and do our best to just
take the nightmare that technology can
become and turn it into a nice pretty
little fuzz ball that you can use to
help your business get done faster
better sharper and allow you to sleep at
night on the other side is someone who
actually never sleeps at night or close
to it Michael and I'm going to let you
introduce yourself hey everyone my name
is Michael Mage I'm also one of the
co-founders of building better
developers developer and I'm also the
founder of Invision QA if you are a
small to midsize business or a small
Healthcare clinician or doctor's office
we help
you identify what systems you have in
place what software uh that you're using
and we also build custom softwares so if
the tools you have aren't quite working
for you we can build you what you need
which actually kind of goes into the
conversation we're going to have today
yeah that's a nice little dove tapil
into we're going to talk a little bit
about it's it's sort of about
requirements and and expectation setting
and level setting and some things like
that and as we were talking about in the
pre-show that you can go watch out on
YouTube it's a little bit idea of like
first you first you're working at just
writing code and then you're sort of
becoming a developer so you're
developing Solutions now you're getting
into the point where you're you're not
maybe you've built your own Solutions
but now it's working with other people
to figure out what they need what is
their problem and how do you figure out
how to solve their problem and give them
a solution that works now there's a
couple ways that we step into this this
this topic I want to focus on which is
uh a disconnect we'll call it one is
it's the we've talked about this before
we've s thrown it out there and Michael
just example like somebody sees I want
to create uh
Twitter and I want to create something
just like Twitter but I'm going to call
it flitter and their you know their
budget is 50 bucks it's like okay you
have no idea aide what's involved it's
not just like changing three lines of
text and then giving it over to you you
have no idea what's involved in the
solution behind there this can also
happen with customers and this is really
where I want to focus little more
because instead of building new stuff
which is more likely to I think normally
draw Us in as far as like Gathering
requirements and walking through that
process with the customer even if they
have done some of that work beforehand
because sometimes you will get
you know a fairly solid list of
requirements but then you're still going
to you you're going through them you're
going to have questions and so it it
naturally progresses when you're dealing
with an existing system that a customer
has there's a two or three different
ways that people look at it one I think
I'll go into three there's the one where
it's an old system that we love it works
great we really don't want to you know
it's not broke don't fix it kind of
thing but we do need to upgrade it
because the technology is being
sunsetted or something like that then
you have the people that are on the
other end that are like we've got this
thing it was a piece of crap it doesn't
work we hate it we've been trying to get
off of it forever and it's now the
technology is sunsetting and we've just
we've waited too long and now we need to
and we want to build something
completely different and then you have
somewhere I guess we'll say in between
where people have something that we have
something not really what we want we've
learned something lessons from it and we
want to build something better now the
good thing is in all three of those
cases you when you come in not only
building better developers we want to
build better Solutions so whether they
love their solution or they hate it or
somewhere in between we want to talk to
them about that solution we want to
understand in this situation what is it
you have today what are the processes
how does it work how does it you know
how is it successful how is it failured
where your paying points it's really
talking before you get anywhere into
what we're going to build for you or
where we're going to go with it let's
really understand what you have now that
can be a challenge because sometimes
you're going to get stuff where they say
well just go work on the application or
here's you know rarely do you get here's
full documentation but they'll be like
here's a user's guide and you'll have an
application with 100 screens that's got
a you know two-page user guide or
something like that and there's all
points in between the thing is this goes
back to something we talk about a lot
it's the why why is that there why how
is it used and it is so easy for even
somebody we'll just say like I could be
an example of where you've done this a
bunch but you don't push on the I need
to understand the business side of it
and that can run you into problems
because now what you're doing is you're
making assumptions you're going to
assume that what the customer tells you
is exactly what's going on and while
sometimes that's correct sometimes it's
not particularly with systems there's a
lot of times that we have gone in and
done assessments and and evaluations and
things like that and you get into it and
you find that maybe you start let's say
you start with the CEO and maybe they're
they like built this from the ground up
so they talk like they know everything
and then you start talking to their team
and you find some people that are like
oh we have this other thing we use it's
not because the CEO is you know not
smart or it's just like people grow and
and move and they do these other things
and there's stuff that's not on their
radar and you'll find those kinds of
things and and even within their systems
they may use it all the time and it's
not and they think that this thing is
just you know a smooth integration and
then you find out that oh no behind the
scenes it's actually like multiple
Integrations they've got Al all these
licenses they've got to have maybe two
or three vendors involved and don't even
get me started if you've had multiple
teams of Developers individuals come in
over the years because this goes back to
some of our other conversations is it
always looks like it was written by 50
different people even if it was three
and so it gets really difficult to
understand what's there because you
can't look at the code unless it's super
super simp you can't look at the code
and know what it does if it's like add a
number subtract a number okay now we're
like then maybe you can look at the code
even a basic crud app where you're just
insert update delete records do some
listing there's probably some
validations in there and if you can't
crawl through all if you don't crawl
through all the code and make sure you
got every little piece of code reviewed
which is very timec consuming you're
probably going to miss something and
even if you do you're probably going to
miss something because it's you know
sometimes hundreds of thousands of lines
of
code so what do we do this goes to we
come back to the fundamentals one we
want to make sure that we are setting
expectations now sometimes your
expectations are going to have
assumptions and you're going to have to
step up when those assumptions are
proved incorrect so for example if you
step into an a project and they say we
really don't have to do anything but
copy these files from A to B and you're
good okay assuming that it's going to
take us x amount of time here's what
we're going to do cool and then you find
out well you can't just copy those
there's some other things that are going
on and there's some stuff over here that
you got to look at and oh these things
can't just be copied they've actually
got to be Rewritten at those points
you're like hold up
stop we made an assumption and now we
have to reset because now the project
has changed what we walked into as we
got further into it we realized that's
not it and you're going to feel bad
sometimes you're GNA have customers
you're going to say hey why didn't you
tell us that up front and you can say we
didn't spend the time walking through
all this code up front and if they
wanted you to or if they want you to
walk through all the code upfront then
you want to make sure you've got some
sort of an agreement or something so
you're getting paid because you don't
want to be in a situation where you
spend weeks of time crawling through
code putting together a nice
requirements document and they're like
ah sorry we're not going to do that and
they walk off and use your stuff
somewhere
else the other part of this is the the
real
fundamental when you're looking at that
application however you're looking at it
even if you can't see the code when
you're looking at the screens in that
ask questions how did I get here what is
this what does this data do where does
this data go where is it used don't be
afraid to just be like a two-year-old
ask questions ask questions ask
questions because that is how you're
going to get the requirements and that's
how you're going to find the things that
are in their head particularly when
they've used this application day in and
day out for years there is so much
knowledge that just they know and they
just know it like they breathe but they
to tell them give me that information
you have to find a way to extract it
you've got to write that ask the right
question and you're going to end up
having to ask a lot of questions because
you won't know that question until you
ask it so that's like a big long-winded
approach and I'm going to toss over
Michael and sort of get your your
feedback on those and what are your
thoughts when you run into these
situations so let me start with a little
bit of current events which kind of ties
into this nicely so the current
debacle that kind of shut down the US
recently uh with an operating system
failure it has been discovered that the
company that was working on the software
only tested their code using unit tests
and unit tests are a form of
requirements or tests built on the
requirements to test the code a certain
way as you're going through these
projects if you're not collecting the
requirements if you're not filling in
those assumptions and updating your
tests if all you're doing is making code
changes running your test good shipping
the software if you never do end to- end
testing or any other validation testing
to make sure that the system works as
the user wants it you're going to break
things so that's what happened which
literally shut down a lot of systems
within the
country flipping back to that so as
developers as we are working our way
through software through new software
integrating software working with a
customer I am very anal about how I go
about Gathering requirements because I
have worked on multiple sides of the
fence uh Rob has too a little bit but
I've decided at one point I need to step
out of development I wanted to be a
tester I wanted to learn more about
integration testing automation testing
and see how I could apply the test
driven development
approach as a developer working on
systems working with customers
especially today since a lot of our work
is done virtually we do a lot of work
through the computer so it's very
important to sit down with your end user
or your customer and have them walk
through the system with you do they have
a login screen well if you have a login
screen you have to ask yourself okay
sure they takes a username and password
but if you have some type of
authentication they probably are not
thinking in their minds that they
probably have role based permissions or
role-based uh interfaces where certain
things happen in the application for
certain people so this person may come
in they're an admin they see everything
in the system it's like cool this is how
it works you build it that way and you
roll it out and next thing you know hey
um why can my customers access payroll
um that shouldn't happen well you didn't
show it to me that way so there's a lot
of nuances with
software that your end user your
customer may not know so you're GNA want
to talk to more than one person if you
can about the
system Rob mentioned writing up software
requirements well sometimes you don't
have the time sometimes you're pitched
with hey we have this so you're going to
make a bid or an initial bid or
statement of work to say hey I can do it
for X based on these
assumptions however once you get in
there very quickly try to find out if
those assumptions are right don't wait
too long if you can catch this within
the first few days you usually have a
little more bandwidth to go back and say
hey we need to re-evaluate this contract
what you pitched us does not match what
we
have however sometimes what you are told
is fairly close to what you have within
the system so you get in there okay
things are going along as expected but
like Rob said there might be assumptions
or things that aren't seen from the end
users
perspective so as you're walking through
an application even even if it's for the
first time at the start of the contract
walk through the user stories so what is
a user story a user story is how a
person interacts with the system what is
the person doing on the keyboard what
are their objectives you know I am
coming to this page to do what what is
my expectation from the application and
what is the results so you're kind of
thinking that blackbox testing
information in information out but
there's stuff that happens there that
you have to break down so that you can
actually write the code or fix the code
or even understand what the code is
doing behind the scenes so this kind of
gets into that whole white box gray box
testing development you have to look at
things to gather this
information and as you're doing this
you're going to find that there are what
are called happy path or for simple user
stories for the basic implementations of
the
system most companies and most users
have that but what they don't have is
all the other things that are required
to keep that happy path working like for
instance with the
login can the user name is it an email
can is uh is it just numeric characters
is it alpha numeric does it have to have
special characters you know what
conditions are required just for the
username password same thing now if I'm
logging into the system okay sure I can
have a user
account but what happens if I you know
what happens if I try to log in three
times does my account get
locked does my account expire if I log
in am I logged in Forever do I never
have to log in again so just in that
scenario alone I've already thrown out
half a dozen scenarios that you need to
think about and account for just for a
login page for from the user's
perspective hey I log into this
application it lets me in if I put in
the right password it doesn't let me in
if I have the an incorrect user name or
password from the end user that's what
they see but from a developer we have to
think about all those nitty-gritty
details to make sure that the
application
works now I've kind of really dragged
down on that path
but it's one of those where attention to
detail from a developer mindset it's not
just about hey I have this feature no I
need to understand how this feature
works and works with the system as a
whole not just that piece because it
could work for me my unit test could
pass but when you get to the end user I
click here to get to this page whoops I
just broke that that doesn't work but my
page works but I've have now broken
other implementations or other features
within the system so you have to be
careful with what you do but you also um
have to think about these things from
the end user's perspective while
thinking about it as a developer so that
way even if you don't do the
requirements you have an idea
to start building the software and if
you do it from a test driven perspective
you're writing all these tests first all
these scenarios first and then you're
building the code that the test will
test so essentially if you're doing a
login okay I have a username I have a
password variable I pass it into this uh
method I should get logged in or I
should be rejected because it's not a
valid password and then you essentially
write those methods and then change your
test to call that method from the
hardcoded pass and test your
code so that's kind of my box on this
part of it uh Rob where some more are
your
thoughts I want to go I do want to say
that when we talk about setting
expectations and the and the whole like
I don't know how many times I've seen
stuff where it's like it's really a
simple project you just have to take
this thing and move it from point A to
pointb I think if you struggle with
getting your customer to understand the
complexities involved I think the login
is one of the most perfect examples to
work with because it is
literally dozens if not more of
decisions that are made with a login and
it is it's stuff like Michael talked
about it's like what's your it's and
some people think oh well it's how long
how complicated is your password and
then what is your you know is your login
a name or is it an email address well
this is where you go a lot deeper is
there's things like okay what characters
aren't allowed what characters aren't
allowed for the name is are you going to
have a display name that this user is
going to be seeing elsewhere in the
system is that their login and if so
that's a security risk because now
somebody at least knows what their login
is and so you don't necessarily want
that which is the same thing if it's
their email address then somebody could
guess their email address and use that
as a login do you want to do that what
happens if they forget their password
what happens if you want to add maybe
initially do or maybe later you want to
add some multiactor authentication how
does that work do you have the ability
which is a lot of systems now have are
you going to need the ability that is
the for admins to log in as a user which
goes a little bit to what Michael said
where you now get to see the system as
that user and not as you as a super user
maybe see a much different system and it
goes on and on it's like well do you log
out what happens when you log out when
you log in do you where do you go do you
go to your homepage does your homepage
change depending on what your role is
and then it just there's so many things
that can be involved there that alone
people are usually like well we just
need to log in and we need to log out
okay let's go into explore that and by
the time you've asked about the 10th
question you say okay that's just the
login we haven't gotten anywhere else
that's why this is complicated
that's why when we say we're trusting
you we're trusting you with a lot if
we're just going to say we trust you
that your login system currently works
fine we're trusting that you've answered
all those questions and that they all
make sense and this goes to a little bit
to the unit testing which is Michael's
idea is like okay let's say that same
login and your login Works flawlessly
but let's say that for example you don't
store a display name or you store
personal information for first and last
name and it's a system where that
shouldn't be displayed anywhere but
everybody else somewhere down the line
says well I just need a name so I'm just
going to take first last name put it
together and then that's that's how I
address them well yeah those both work
fine but when you put it into the system
you're not following a story and I think
that's probably where we're going to go
next but not right now because we have
gotten a little long on this one as we
sometimes do and we are going to wrap
this one up and go work on our
requirements because that's what we do
as always we can gather requirements
from you by sending us emails at info
developer.com you can check us out on
developer nerd.com we've got a form
there you can sign up you can leave us
comments you can see tons and tons of
com of content you can check us out at
school. developer.com and see some of
the like the really short less than an
hour up to
multi-day tutorials and and lessons and
classes that we've got
there subscribe wherever you subscribe
to podcast and then three other places
as well just cuz and you can get this uh
we're going to drop we drop this twice a
week out on the YouTube channel you get
to see that twice a week if you're
listening you get bonus material
although you can I mean you can always
color us out so you don't have to watch
us but there's extra content as well out
on the YouTube channel that's the
developer or Channel out on YouTube you
can go find us there plus pass
Mastermind Mentor sessions and things
like that as well so there's tons of
content and now I'm going to take a deep
breath and go grab a glass of water or
something like that but for you go out
there and have yourself a great day a
great week and we will talk to you next
time bonus
material so it's funny as you were
talking about the
school uh site um because remember I've
got that entire course out there on
software requirement documentation and
software test documentation so um that
that's a good source and we got lots of
content on the site about testing and
writing uh documentation things of that
nature one thing I would add to this
particular conversation though
is when you go into your conversations
with your
customer well we are giving them the
power because they are essentially The
Keeper of the keys they are The Keeper
of the knowledge of what the system is
doing or what they want it to do we have
to make the assumption that one we know
nothing we have assumptions but we know
nothing about what they have or what
they want unless we've been working on
so if you're coming in fresh assume
nothing assume everything's
wrong
two take anything someone gives you for
a requirement and pick the hell out of
it if there's anything that is a what if
or an if then in the requirements and
there is no distinction of what the then
is it's not a
requirement it needs to go back and be
clearly defined because your
requirements should be one task or
essentially how the feature Works should
be feature complete it should be if this
then this if this then this there should
not be if if I do this I might get this
oh wait we might also get this or wait
we might also get this if you get into
the code or you get into the requirement
and you read this and then you say well
wait what about this what about this
what about if there's any questions at
that point you need to stop and redefine
that
requirement uh because if you start
writing code to
that you may throw it all away because
it could be completely wrong so you have
to be very careful about that for your
time because if you do that the customer
may not pay you again to fix it you may
have to eat that cost because you made
the Assumption went off and did that
when the customer really wanted
something else done so you have to be
careful as you go out and start building
these
applications Rob one followup to that
and then we'll we'll wrap this one up is
I do want to talk a little about along
with setting expectations and
requirements in that is
making sure that there is along with all
this
what the easiest thing to say is what
done is is there's a lot of times that
we get to a point we do this with our
personal applications I know customers
do this all the time as you get towards
the end and then it's like oh can you do
this can you do that can you make this
little change can you do that little
change hey can we just do this can we do
that and it may be and it is
frustratingly simple sometimes it's like
yes I can change those three letters and
change that label or yes I can change a
number and it's going to change the
color of that button or whatever it
happens to be a lot of times they very
simple changes the moral of this story
is there's no such thing as a simple
change if you touch the code there is
potential particularly as you get later
into a project there is potential that
you are going to have a typo that you're
going to have something that didn't go
right that you're going to actually you
know that these days you got to watch
out AI stuff will insert code on on you
I don't know how many times that has
frustrated me I've had to go turn things
off because you go and it complete
autocomplete something incorrectly for
you and if you're not paying attention
you're like wait I would have never
typed that what was what kind of idiot
oh the AI idiot that's the one
so don't ever assume it like everything
this gets into like the whole idea of
like this is why with scrum you use
points instead of hours the minimum the
minimum thing you
do assume it's going to take half hour
an hour something like that maybe more
than that use that to focus them on what
gets us to done and the extra stuff we
will get there we can add that later
we'll do that in another
release what we're going to do in
another release is we'll step into
another topic but for now I think we've
gone long enough and we will get on our
way as always check us out at all of the
race places leave us some comments shoot
us an email at info develop or.com and
we will check you guys out
next time around
[Music]