Detailed Notes
In this episode, we delve deeper into the developer’s journey, focusing on how to handle the toughest non-happy path scenarios—those we now refer to as “Psychopaths.” These are the rare, unpredictable issues that disrupt normal workflows and often present the biggest challenges for developers. Let’s explore what “Psychopaths” are, why they matter, and how you can improve your skills to handle them effectively.
Read More... https://develpreneur.com/unpacking-psychopaths-scenarios-and-tough-coding-challenge
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
* User Stories Unveiled: A Developer’s Guide to Capturing the Full Narrative (https://develpreneur.com/user-stories-unveiled-a-developers-guide-to-capturing-the-full-narrative/)
* Misdirection Anti-Pattern: Solving The Wrong Problem (https://develpreneur.com/misdirection-anti-pattern-solving-the-wrong-problem/)
* 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/)
Transcript Text
[Music] and here we are uh we are back and we are thinking about our topic this time around um I'm thinking a little bit I was trying to think about how to do a little bit of a tribute to our latest uh conversation and the New Concept that we came up with or that actually she came up with um and I think it is I think there is I think that because we've talked we haven't really we've talked a little bit about requirements and about asking the questions but it I think it's an area that it's useful to go into a little bit about some some ways to do for both testing and for requirements Gathering things that are not the happy path effectively is what are the thing that like the things that are out there that are besides the like especially when you're talking to a customer that's building something out the particularly something that doesn't exist if it's a brand new product it's like okay I know you've got your vision but then finding a way to ask them the questions that bring out the other requirements and a lot of times it's stuff like I had a conversation with a guy today it was like here's what we can do and he's like what do you recommend and I SED to go back I was like well really depends actually this one got into like pricing and pricing engines and stuff like that and it's like well you know how much of it is you you do you need entry level thing do you need to you know do you want to make it easy do you want to make it very configurable because usually those two aren't the same you know things like that and it's those kinds of things that we get into and I it's it's even goes into testing it's the same thing it's like okay somebody writes you know five unit test for a a function but then it breaks all over the place because they didn't really test stuff so there's like your you know there's your basics of this this and this you know some of your like there's those standard rules of here's some things you should look at if it's like if it's a number or even if it's doing any kind of computation here's the things you want to look for these are the things that you can sort of you can always use to just spew out you know like unit tests and even testing in general but then you get into the other things and it's how do you dig into the other things and I think it is it's something as a Dev it is a developer Journey as far as learning some of those things so that's what I'm thinking is it's sort of like the um everything but the happy path as a as a topic for this first one yeah so you're thinking well and this could also get into like that muscle memory like we talked about last week where people don't think about it you know those are those requirements that it you don't ever I mean it's been so long you don't think about it and it's like that's not a requirement that's just what I do and it's like well what you do is the requirement you know how do you do it what you know what is it and some it's like oh yeah I guess that doesn't just happen I do this and it's like oh yeah you do it's like you know it's like some people it's like it's like brushing their teeth in the morning they don't think about if you ask them how was your toothbrushing experience this morning they'll be like I don't remember because they do it all so often but they do it so it would be easy to forget you know it's things like that yeah that' be that would be a good followup to the ones that we did and also our post uh 800 so this is 801 guys oh cool we are into the big league actually we've been there for a while now actually because I don't think that Apple only keeps the last 300 so you have to like specifically go back to the the early ones which is probably good at this point deep breath here we go well hello and welcome back we are continuing our season where we are going through the developer Journey we are building better developers we are a develop andur I am Rob Broadhead I am one of the founders of developing or and in keeping with our uh our standards now in the last few episodes we talked about a little good and bad uh good thing bad thing and then uh throw a little extra uh introduction to it I'll do the introduction first because I got to think about my good and bad uh I was going to reverse it and then I lost it I am also the founder of RB Consulting where we integrate simplify and automate and find ways for you to find the best way to leverage your technology investment whether it's people whether it's it's languages or applications or whatever it happens to be good thing bad thing uh good thing this is actually a fun one so good thing is I managed to go to a store that uh for people around here it's it's place called M and they just take back old it's like it's a used store a used store used media store it's not just bookstore they do video games and a whole bunch of crap and I had just boxes of stuff that was sitting around basically because I've just had kids move out and we took it there and got a bunch of credit introduced the kids to it so now they know that they can take their old crap there they can get new stuff which they did they're new to them they can go get like books and stuff like that so that was a good thing bad thing is uh I don't want to get political but I watched the debate last night and it was the most ridiculously bad thing ever it's just like it wasn't a total waste of time but it was definitely like you could do better like to everybody everybody involved you could do better you could be more entertaining you could do a lot of stuff better but that's sort of the way things go these days somebody that also Maybe not maybe cannot do anything better is sitting on the other side of the screen for me Michael go ahead and introduce yourself hey everyone my name is Michael M I'm one of the co-founders a developer ner I'm also the founder of Envision QA where we build software tailored to meet the unique needs of healthcare professionals and small to midsize e-commerce businesses you know whether you're a healthcare provider or an e-commerce entrepreneur partnering with Envision QA means unlocking your software for full potential experience the confidence of knowing your software meets the highest quality and compliance standards while driving success in your industry good and bad let me start with the good so I guess the good news um I missed the debate I missed all that chaos uh getting back on track this week because on the bad side life happened um some uh Health ISS isues hit the family last week and we were down for quite a few days and unfortunately had some very bad experiences with the general uh Health Care system of our local General Hospital so can only strive for better and with that I'll pass it back to you maybe that'll be another one we'll do building better hospitals that'll be like the next thing to get into today we're going to talk about how do you get better well one of the things is it's uh it's a little little bit of like you get better because you just do it it's like the more you do it the more you get better we want to I want to talk about this thing that we've we've come up with a new term and actually it was because we're in a conversation with a a client and we're just going to call that client Melissa and Melissa came up with an idea as we were talking about the happy path and we were talking about the things that aren't the happy path and she interjected and said oh the Psychopaths and I was like that is so on point to what we often run into that we're going to use that so she's like you know just make sure I was like how can I mention your name and even if it's like a you know in quotes and everything and so we were able to do that and so we're stealing that for now so we will use Psychopaths for quite a while because I just find that very appropo when we're talking about everything not everything but a lot of the things that are not the happy path particularly the things that tend to bite Us in the butttocks as Forest gumps likes to say those things that are like outside of the norm the outliers the things that are just rare but it's like those are the ones that always get us and I want to talk about getting into that because there are probably like two situations that we run into where those are very very difficult there are others where they can be it's a challenge but the ones that are most difficult are where there is where we're talking about like a brand new application brand new solution so it doesn't exist except in the person's head head and usually this is an entrepreneur or Visionary type person and so the whole like rubber meets a road is not really in their wheelhouse either and so you have to find a way to take that vision and ground it into you know bring it down to earth and then start looking at all of the warts that could possibly come out of it similar to that maybe uh although it's a little easier is when it's an existing system and that somebody just does it uh you think of it like almost like muscle memory so you're trying to figure out where are the things that they just know how to do but they're not going to think about it it's like if you if you ask them they can give it to you they'll like yeah this is what you do this is how it works the problem is you have to know what to ask so as you get into these things early on when you're starting out in your career you're probably going to find that there are you're going to like almost out of the gate be able to come up with some things that are how can this fail and the common things everybody I think you know right away we'll find things like well you look at you know is it a maximum value is it a minimum value um sometimes people right away figure out what if there is no value and it's like okay cool as you get a little further on you will bump in to the off by one error so you'll very quickly say it's not just the maximum error it's the maximum Value Plus One and minus one the minimum value plus one and minus one because there's a big difference between less than and equals or less than and greater than and equals or greater than and you will get bit by it at some point whether it's design issue or whether it's just typos or all sorts of things and of course there's the whole equals as opposed to less than or as opposed to greater than which usually it's going to come more around your uh copy paste and stuff like that but it's like fine like it really does get into almost St statistical analysis of like find like a middle absolute middle of the road something on the first quartile and the third at both ends and right on the cusps of both ends and then is it a you know does the value exist at all what if it and then you start getting into things like well what if they try to find a way to put a value that doesn't exist one of the things like a good example you'll run into probably at some point is where somebody's typing a number and it should just be a number but they decide to put a comma for their thousands or a point for their thousand separator or something like that if you don't have a you know depend on how you have stuff set up that might sneak through and the next thing you know you're like what the heck is this or they put a a you know a currency sign a dollar sign or something like that on the front of it and you just want a number so now you got to figure that kind of crap out and don't even get me started on like date formats and phone number formats and things like that and especially you have to in a lot of these cases you're going to start thinking through the things where there are varying forms of it because you're going to assume certain things like for example there was a point where people assume that all years you really only cared about the last two numbers and then they found out that when you got to about 1999 to 2000 you did care about all four numbers and so there was you know those things happen now you're ask you may say okay great you've thrown out a lot of things you may even know what a lot of these are and so how is it that we figure out how we know what we don't know and this is where it does go back to as we've talked about before a lot of it is asking questions but a lot of it is sitting down and saying okay here's your process and I think the easiest way to do it is find your best way to take the the happy path whatever that path is and then dissemble it into the steps that are involved and then that allows you with every step that's involved to apply what you know to each of those steps which is basically what happens if the inputs are incorrect what happens if the outputs come out wrong what happens if the step gets skipped what happens if this step is going on and another step triggers those kinds of things that kind of line of thinking is what's going to get you into those kinds of questions and to help you get those Psychopaths which are truly some of the nastiest things if you try to do like real-time processing and it's parallel and you get into race conditions and things like that that the first time and that is not like this is not about like you know I'm a black guy a white guy a red not not that kind of race this is like running really fast race and both people both things finished at the exact same time then who's the winner you can't have a tie so what happens or things like that that you will run into or even like maybe you can't have a tie and then you do and it's called a deadlock or something along those lines these are the things that you will run into when you start breaking down those steps and applying that how can it go wrong in the most really in like the most granular way it's like because then it's limited now you're not having to think about entire systems of issues now you're going to those specific things and you're basically saying here's you know whatever your your ability is to guess or to you know assume that these are the things that can go wrong maybe there's four T items or 10 but the important thing is that now you can take all those apply those to each step and you don't have to figure out the whole system of exploding stuff when things go wrong you can go to that specific thing and say okay this thing what are all essentially what are all the Poss M States and then from there you can re work your way through it because at the end of the day we're basically almost always dealing with a state machine of some sort or another and so if you can nail down the states then you can nail down the process itself and figure out where it can go wrong or at least what you need to do if it gets into a state that it potentially shouldn't be and now this is also a near and dear to the heart of anybody that's in testing because this is the this is the other side of it it's like okay you're telling me this is a requirement I need to think of all the ways that can go wrong so I can test it and verify that it's going to work in all of the situations the last thing before I throw it over to Michael is just the biggest thing that you will save yourself headaches from is to not assume if you assume things will be a certain way you will find out that they won't and you have problems it's things that never never happen like outliers like you have a huge server and it runs out of dis space and suddenly your web application that doesn't even know what dis space is effectively doesn't run because somebody can clean up the log files or something along those lines so don't assume sit there and like really try to think like where can you possibly be assuming things so you can figure out where you can ask the right questions and now I'll toss it over to Mike wow that was a lot so I don't want to get on my soap box too much because I could so go way too far in many directions one of the things Rob touched on so many good points and what I'm going to bring to this conversation is a staying on this topic but from an example perspective so in my 25 plus years 30 years of working in this industry I have worked through the Journey of here's a ticket go write a task you go build it you test it as a developer hey what I did work but I didn't test the whole system things break down the road you don't think to test other things you only work on what you work on As you move into your middle career it's like oh I'm going to start asking more questions like Rob said you're going to look at those you know off by1 errors you're going to look at what type of data you need in your system those Deadlocks things of that nature and as you move further along in your career or if you're like me and you like to jump and wear many hats just do too many startups and you just wear every hat you come to find out that you from a project owner's perspective a business manager or a tester's perspective you look at things different you look at the systems you look at the stories you look at these requirements in a totally different way so like Rob gave so many great examples I'm going to walk you through a couple scenarios here so first of all from a tester's perspective we take a ticket we take a requirement for instance login happy path user should be able to enter in a valid username and password and log into the system perfect simple negative path user enters in an invalid username and password and they shouldn't be able to log it's still a happy path but it's a negative use case some of the weird cases could be if you don't have have the right logic in the background what happens if you throw in a SQL command in the username or in the password you now get a SQL injection error because you have something weird in the background and now suddenly your database is deleted and things go wrong so from a tester from a like just a user story looking at the requirements you have to assume that what you're given is wrong if you're a tester we have to always assume things are wrong but as a developer when we're handed a ticket for the first time if we're doing agile correctly if we're going through our Sprints correctly we're going to walk through the requirements of the ticket walk through what the ticket or what the requirement is supposed to be how does it impact the system as a whole what are the acceptance criteria what are the things that we can kind of let slide in this particular ticket because some work precedes other work so you are going to potentially write B bugs or feature or future feature um conditions or uh features into code that aren't necessarily turned on yet or maybe feature incomplete so you have there will be things that won't work but the thing is in the ticket in what we're looking for we should know what we're doing so when we look at these tickets and we talk through these tickets you should always be asking yourself are there any questions that are not there for instance login screen well what happens so I just gave you those two scenarios you know happy path login negative case still happy path user logs in with invalid credentials is kicked out but nowhere in those requirements specifies hey what happens if I get bad data or weird data or a SQL command if you leave out things like that it's not going to get coded you potentially could leave yourself open for problems or the feature is not going to work as expected so we have to ask ourselves looking at a requirement for for instance just a screen like I said the login screen so you have two Fields you have a username and password well from a web perspective or even an application perspective are they alpha numeric do they allow special characters do any input Fields these are things you should ask uh is it uh numeric only can I allow SQL should I look for specific commands do I need to mask the data you know is this data being stored into a database do I need to set a max length a minimum length do I have to add specific criteria oh I need uppercase letters lowercase letters I need numbers I need special characters it has to be a minimum of a certain length and if it's not and they try to log in or they try to create this information what do we communicate to the user that they've done wrong other than oh hey you can't log in or oh hey you can't create a password what do you tell the user so you have to also think about the error handling behind the scenes as well as what is displayed to the user so a simple login page hey build me a login page to allow users to log in sure sounds easy but there are so many layers to unpack with that that this is just one example of how to kind of peel back the onion when you're dealing with these type of situations now a recent one we both uh were looking at is we were trying to walk through the requirements with a customer and we started running across things that we started realizing were muscle memory these were things that the users were doing that they weren't thinking about so to them it just worked as it it's supposed to but they weren't communicating to us what it is that they were doing and what it was that they were expecting from the system or that the system should do so when we go to code this or work in a similar solution without this things are going to break people may not get paid you know customers may not get their products on time so you always have to look at the little pieces you know you may have the high level you know big road map site map whatever but you need to pick at it you need to literally get into those nitty-gritty details and at the end of the day if you think from a tester perspective look at the use cases the user stories for that given ticket and if you can write every single user story you can write those tests first then write the code and then next time you go to make a change to this if you break one of those user stories you'll know immediately the code will never make it out the door and then you go back and you have to fix it before introducing a bug to the end user you know we don't want to be like that one company that took Microsoft down all across the world so again these are those Psychopaths those paths that you may not always look at with your stories you have to get to those details you have to talk to the customers and sometimes you literally just have to sit there and watch what the end user does it may be boring as heck but watch what they do they may do what they say they do great record that if they don't do what they say they do stop them and find out why or just pay attention and see what use case they just introduced that has not been communicated and finally the other thing you want to look at when you're watching that is are your end users or is the prospective customer doing things outside of the system that again is that muscle memory or a process they've introduced to work with their current systems because their systems don't do it so they have built a system on top of a system that you have to kind of unpack and figure out what that psychopath is to put those requirements into a ticket to make sure that your functionality that this software that you're building meets the customer's demands that is that last part is probably the best is you can say tell me and you're going to get something if you say show me you will get something different a lot particularly if you're dealing with an existing system with a call them a you know a power user or a a user that has been on this for a long time because as Michael said a lot of times they'll have their own systems I've been at places where they've got these huge systems and they'll tell you that they use them for everything and you sit down in 2 seconds into it realize that they've got Post-it notes or they've got exra little spreadsheets they've got all this stuff it's like well what is that oh I use that so I can get this thing and it's just it's the kind of stuff you're like well wait a minute you said you only use a system then what happens if that's not there well that never happens because I always sit down at my desk and my Post-It note is always there it's it's those kinds of things that you need to you need to find a way to get to it and sometimes you're not told it because people want to tell you the right way to to do it which is not the real way that they do it and that's where show me is so much more value sitting down and this is I think lost a lot when we have so many remote uh you know engagements and stuff like that and I was very frustrated in one not too long ago where it's like it was third and fourth hand information as opposed to just being able to get boots on the ground and watch somebody do it and how they use the application and how they use the system and be able to actually say okay what's actually going on because in this case it's one of those you get to a point where you say okay well how is this getting used and they say they use it like this I think it's like well wait a minute you think if you don't know then we need to go like who can say definitively what the answer is now in a very similar vein you can say definitively what you think about us and what your suggestions are for us by sending us an email at info developer.com you can contact us out on developer.com on our contact form you can put comments wherever you see us whether it's out on YouTube and the developer ner Channel whether it's out on whatever your favorite podcasting tool is uh or your actually podcast listening device is all of that stuff wherever it is leave us comments send us com smoke signals we really don't care however you get it to us we want to hear from you we want that kind of feedback because it helps us help you help us be better building better developer podcasters so we can help you build better developers essentially that kind of thing we are not done though we are continuing this season we have tripped at the 800 Mark apparently in number of EP episodes which is in itself sort of mind-boggling thinking back to like when it went to like double digits it was like wow I made it to 10 and now we're quite a bit away from that so we're just marching along we will come back with uh more on the developer Journey next time around until then go out there and have yourself a great day a great week and we will talk to you next time bonus material uh I have quite a bit so real quick so I try not to touch on too much I try to keep it on track as we talked about watching your users trying to figure out what they do look at tools like snag it look at QuickTime if you're on MacBooks use recording tools do do anything you can to capture what the user does while they're doing it will help you immensely figure out one what it is they're doing two if the software works or not if there's any bugs in the current system that you need to avoid and three you find out what they are not telling you when they're doing what they're doing that is that's a nice little follow-up the best thing you can do whether this goes for bug reporting too people love to send you a screenshot and it's like an error message and you almost always are going up falling out how did you get there and sometimes they're going say I don't know but then so then you're like okay well next time you get to that try to remember what you did so you can help me get to that uh but recording stuff is huge I worked with the company for a while that that was one of the things they did all the time so they would get bugs and the guy that was effectively this is like one of those it's a smaller company it's a guy that's effectively the CIO would get on calls with people and he would walk through stuff so he could understand so he could actually record the error or the bug and then he would put that as part of the ticket that went into the system so whether and whether whoever it was that got it could sit down and had everything they needed to know on how to reproduce it and he would you know he could throw stuff in there comments like this is what we should expect or we should be able to see this thing and sometimes even show you this is how it should work this is the path they took and it obviously doesn't work so recording is huge not just don't trust people actually even yourself when you're doing this kind of stuff is like what all did I do to get to that there's times you can't remember either so the more you record the more you can actually watch and observe the better that's all going to be that will wrap this one up and we're going to dive right back into our next topic next time around for you depending on when you're seeing this it may be a couple of days or you could go bam right into the next one that being said as always feel free to leave us comments leave us feedback we love to hear from you however you want to engage with us we're happy to do so whether you want to continue doing this on YouTube or whether you want to just listen to our incredible voices while you're driving a car exercising or something like that always happy to do so we are uh always looking for new topics next season we've got some really cool stuff coming back we've already talked about we sort of threw some bonuses out a while back on where we're going with that we'll probably drop a hint or two again in case you miss that one if not go back and listen to every single prior episode and maybe you'll find it somewhere hidden in there little Easter egg that's being said it's time for you to get out there and get back to work and for us to go figure out what we're going to talk about next time so have yourself a great one we'll talk to you later [Music]
Transcript Segments
[Music]
and here we are uh we are back and we
are thinking about our topic this time
around
um I'm thinking a little bit I was
trying to think about how to do a little
bit of a tribute to our latest uh
conversation and the New Concept that we
came up with or that actually she came
up with um and I think it is I think
there
is I think that because we've talked we
haven't really we've talked a little bit
about requirements and about asking the
questions
but it I think it's an area that it's
useful to go into a little bit about
some some ways to
do for both testing and for requirements
Gathering things that are not the happy
path effectively is what are the thing
that like the things that are out there
that
are besides the like especially when
you're talking to a customer that's
building something out the particularly
something that doesn't exist if it's a
brand new product it's like okay I know
you've got your vision but then finding
a way to ask them the questions that
bring out the other requirements and a
lot of times it's stuff like I had a
conversation with a guy today it was
like here's what we can do and he's like
what do you recommend and I SED to go
back I was like well really depends
actually this one got into like pricing
and pricing engines and stuff like that
and it's like well you
know how much of it is you you do you
need entry level thing do you need to
you know do you want to make it easy do
you want to make it very configurable
because usually those two aren't the
same you know things like that and it's
those kinds of things that we get into
and I it's it's even goes into testing
it's the same thing it's like okay
somebody writes you know five unit test
for a a function but then it breaks all
over the place because they didn't
really test stuff so there's like your
you know there's your basics
of this this and this you know some of
your like there's those standard rules
of here's some things you should look at
if it's like if it's a number or even if
it's doing any kind of computation
here's the things you want to look for
these are the things that you can sort
of you can always use to just spew out
you know like unit tests and even
testing in general but then you get into
the other things and it's how do you dig
into the other things and I think it is
it's something as a Dev it is a
developer Journey as far as learning
some of those things so that's what I'm
thinking is it's sort of like the um
everything but the happy path as a as a
topic for this first one yeah so you're
thinking well and this could also get
into like that muscle memory like we
talked about last week where people
don't think about it you know those are
those requirements that it you don't
ever I mean it's been so long you don't
think about it and it's like that's not
a requirement that's just what I do and
it's like well what you do is the
requirement you know how do you do it
what you know what is it and some it's
like oh yeah I guess that doesn't just
happen I do this and it's like oh yeah
you do it's like you know it's like some
people it's like it's like brushing
their teeth in the morning they don't
think about if you ask them how was your
toothbrushing experience this morning
they'll be like I don't remember because
they do it all so
often but they do it so it would be easy
to forget you know it's things like that
yeah that' be that would be a good
followup to the ones that we did and
also our post uh 800 so this is 801 guys
oh cool we are into the big league
actually we've been there for a while
now actually because I don't think that
Apple only keeps the last 300 so you
have to like specifically go back to the
the early ones which is probably good at
this
point deep breath here we
go well hello and welcome back we are
continuing our season where we are going
through the developer Journey we are
building better developers we are a
develop andur I am Rob Broadhead I am
one of the founders of developing or and
in keeping with our uh our standards now
in the last few episodes we talked about
a little good and bad uh good thing bad
thing and then uh throw a little extra
uh introduction to it I'll do the
introduction first because I got to
think about my good and bad uh I was
going to reverse it and then I lost it I
am also the founder of RB Consulting
where we integrate simplify and automate
and find ways for you to find the best
way to leverage your technology
investment whether it's people whether
it's it's languages or applications or
whatever it happens to be good thing bad
thing uh good thing this is actually a
fun one so good thing is I managed to go
to a store that uh for people around
here it's it's place called M and they
just take back old it's like it's a used
store a used store used media store it's
not just bookstore they do video games
and a whole bunch of crap and I had just
boxes of stuff that was sitting around
basically because I've just had kids
move out and we took it there and got a
bunch of credit introduced the kids to
it so now they know that they can take
their old crap there they can get new
stuff which they did they're new to them
they can go get like books and stuff
like that so that was a good thing bad
thing is uh I don't want to get
political but I watched the debate last
night and it was the most ridiculously
bad thing ever it's just like it wasn't
a total waste of time but it was
definitely like you could do better like
to everybody everybody involved you
could do better you could be more
entertaining you could do a lot of stuff
better but that's sort of the way things
go these days somebody that also Maybe
not maybe cannot do anything better is
sitting on the other side of the screen
for me Michael go ahead and introduce
yourself hey everyone my name is Michael
M I'm one of the co-founders a developer
ner I'm also the founder of Envision QA
where we build software tailored to meet
the unique needs of healthcare
professionals and small to midsize
e-commerce businesses you know whether
you're a healthcare provider or an
e-commerce entrepreneur partnering with
Envision QA means unlocking your
software for full potential experience
the confidence of knowing your software
meets the highest quality and compliance
standards while driving success in your
industry good and
bad let me start with the good so I
guess the good news um I missed the
debate I missed all that chaos uh
getting back on track this week because
on the bad side life happened um some uh
Health ISS isues hit the family last
week and we were down for quite a few
days and unfortunately had some very bad
experiences with the general uh Health
Care system of our local General
Hospital
so can only strive for better and with
that I'll pass it back to you maybe
that'll be another one we'll do building
better hospitals that'll be like the
next thing to get into today we're going
to talk about how do you get better well
one of the things is it's uh it's a
little little bit of like you get better
because you just do it it's like the
more you do it the more you get better
we want to I want to talk about this
thing that we've we've come up with a
new term and actually it was because
we're in a conversation with a a client
and we're just going to call that client
Melissa
and Melissa came up with an idea as we
were talking about the happy path and we
were talking about the things that
aren't the happy path and she
interjected and said oh the Psychopaths
and I was like that is so on point to
what we often run into that we're going
to use that so she's like you know just
make sure I was like how can I mention
your name and even if it's like a you
know in quotes and everything and so we
were able to do that and so we're
stealing that for now so we will use
Psychopaths for quite a while because I
just find that very appropo when we're
talking about everything not everything
but a lot of the things that are not the
happy path particularly the things that
tend to bite Us in the butttocks as
Forest gumps likes to
say those things that are
like outside of the norm the outliers
the things that are just rare but it's
like those are the ones that always get
us and I want to talk about getting into
that because there are probably like two
situations that we run into where those
are very very difficult there are others
where they can be it's a challenge but
the ones that are most difficult are
where there is where we're talking about
like a brand new application brand new
solution so it doesn't exist except in
the person's head head and usually this
is an entrepreneur or Visionary type
person and so the whole like rubber
meets a road is not really in their
wheelhouse either and so you have to
find a way to take that vision and
ground it into you know bring it down to
earth and then start looking at all of
the warts that could possibly come out
of it similar to that maybe uh although
it's a little easier is when it's an
existing system and that somebody just
does it uh you think of it like almost
like muscle memory so you're trying to
figure out where are the things that
they just know how to do but they're not
going to think about it it's like if you
if you ask them they can give it to you
they'll like yeah this is what you do
this is how it works the problem is you
have to know what to
ask so as you get into these things
early on when you're starting out in
your career you're probably going to
find that there are you're going to like
almost out of the gate be able to come
up with some things that are how can
this fail and the common things
everybody I think you know right away
we'll find things like well you look at
you know is it a maximum value is it a
minimum value um sometimes people right
away figure out what if there is no
value and it's like okay cool as you get
a little further on you will bump in to
the off by one error so you'll very
quickly say it's not just the maximum
error it's the maximum Value Plus One
and minus one the minimum value plus one
and minus one because there's a big
difference between less than and equals
or less than and greater than and equals
or greater than and you will get bit by
it at some point whether it's design
issue or whether it's just typos or all
sorts of things and of course there's
the
whole equals as opposed to less than or
as opposed to greater than which usually
it's going to come more around your uh
copy paste and stuff like that but it's
like fine like it really does get into
almost St statistical analysis of like
find like a middle absolute middle of
the road something on the first quartile
and the third
at both ends and right on the cusps of
both ends and then is it a you know does
the value exist at all what if it and
then you start getting into things like
well what if they try to find a way to
put a value that doesn't exist one of
the things like a good example you'll
run into probably at some point is where
somebody's typing a number and it should
just be a number but they decide to put
a comma for their thousands or a point
for their thousand separator or
something like that if you don't have a
you know depend on how you have stuff
set up that might sneak through and the
next thing you know you're like what the
heck is this or they put a a you know a
currency sign a dollar sign or something
like that on the front of it and you
just want a number so now you got to
figure that kind of crap out and don't
even get me started on like date formats
and phone number formats and things like
that and
especially you have to in a lot of these
cases you're going to start thinking
through the things where there are
varying forms of it because you're going
to assume certain things like for
example there was a point where people
assume that all years you really only
cared about the last two numbers and
then they found out that when you got to
about 1999 to 2000 you did care about
all four numbers and so there was you
know those things
happen now you're ask you may say okay
great you've thrown out a lot of things
you may even know what a lot of these
are and so how is it that we figure out
how we know what we don't
know and this is where it does go back
to as we've talked about before a lot of
it is asking questions but a lot of it
is sitting down and saying okay here's
your
process and I think the easiest way to
do it is find your best way to take the
the happy path whatever that path is and
then dissemble it into the steps that
are
involved and then that allows you with
every step that's involved to apply what
you know to each of those steps which is
basically what happens if the inputs are
incorrect what happens if the outputs
come out wrong what happens if the step
gets skipped what happens if this step
is going on and another step triggers
those kinds of things that kind of line
of thinking is what's going to get you
into those kinds of questions and to
help you get those Psychopaths which are
truly some of the nastiest things if you
try to do like real-time processing and
it's parallel and you get into race
conditions and things like that that the
first time and that is not like this is
not about like you know I'm a black guy
a white guy a red not not that kind of
race this is like running really fast
race and both people
both things finished at the exact same
time then who's the winner you can't
have a tie so what
happens or things like that that you
will run into or even like maybe you
can't have a tie and then you do and
it's called a deadlock or something
along those lines these are the things
that you will run into when you start
breaking down those steps and applying
that how can it go wrong in the most
really in like the most granular way
it's like because then it's limited now
you're not having to think about entire
systems of issues now you're going to
those specific things and you're
basically saying here's you know
whatever your your ability is to guess
or to you know assume that these are the
things that can go wrong maybe there's
four T items or 10 but the important
thing is that now you can take all those
apply those to each step and you don't
have to figure out the whole system of
exploding stuff when things go wrong you
can go to that specific thing and say
okay this thing what are all essentially
what are all the Poss M States and then
from there you can re work your way
through it because at the end of the day
we're basically almost always dealing
with a state machine of some sort or
another and so if you can nail down the
states then you can nail down the
process itself and figure out where it
can go wrong or at least what you need
to do if it gets into a state that it
potentially shouldn't be and now this is
also a near and dear to the heart of
anybody that's in testing because this
is the this is the other side of it it's
like okay you're telling me this is a
requirement I need to think of all the
ways that can go wrong so I can test it
and verify that it's going to work in
all of the
situations the last thing before I throw
it over to Michael is just the biggest
thing that you will save yourself
headaches from is to not assume if you
assume things will be a certain way you
will find out that they won't and you
have problems it's things that never
never happen like outliers like you have
a huge server and it runs out of dis
space and suddenly your web application
that doesn't even know what dis space is
effectively doesn't run because somebody
can clean up the log files or something
along those lines so don't
assume sit there and like really try to
think like where can you possibly be
assuming things so you can figure out
where you can ask the right questions
and now I'll toss it over to
Mike wow that was a lot so I don't want
to get on my soap box too much because I
could so go way too far in many
directions one of the things Rob touched
on so many good points and what I'm
going to bring to this conversation is a
staying on this topic but from an
example perspective so in my 25 plus
years 30 years of working in this
industry I have worked through the
Journey of here's a ticket go write a
task you go build it you test it as a
developer hey what I did work but I
didn't test the whole system things
break down the road you don't think to
test other things you only work on what
you work on As you move into your middle
career it's like oh I'm going to start
asking more questions like Rob said
you're going to look at those you know
off by1 errors you're going to look at
what type of data you need in your
system those Deadlocks things of that
nature and as you move further along in
your career or if you're like me and you
like to jump and wear many hats just do
too many startups and you just wear
every hat you come to find out that you
from a project owner's perspective a
business manager or a tester's
perspective you look at things different
you look at the systems you look at the
stories you look at these requirements
in a totally different way so like Rob
gave so many great examples I'm going to
walk you through a couple scenarios here
so first of all from a tester's
perspective we take a ticket we take a
requirement for instance login happy
path user should be able to enter in a
valid username and password and log into
the system perfect
simple negative path user enters in an
invalid username and password and they
shouldn't be able to log it's still a
happy path but it's a negative use case
some of the weird cases could be if you
don't have have the right logic in the
background what happens if you throw in
a SQL command in the username or in the
password you now get a SQL injection
error because you have something weird
in the background and now suddenly your
database is deleted and things go wrong
so from a tester from a like just a user
story looking at the requirements you
have to assume that what you're given is
wrong if you're a tester we have to
always assume things are wrong but as a
developer when we're handed a ticket for
the first time if we're doing agile
correctly if we're going through our
Sprints correctly we're going to walk
through the requirements of the ticket
walk through what the ticket or what the
requirement is supposed to be how does
it impact the system as a whole what are
the acceptance criteria what are the
things that we can kind of let slide in
this particular ticket because some work
precedes other work so you are going to
potentially write B bugs or feature or
future
feature um conditions or uh features
into code that aren't necessarily turned
on yet or maybe feature incomplete so
you have there will be things that won't
work but the thing is in the ticket in
what we're looking for we should know
what we're doing so when we look at
these tickets and we talk through these
tickets you should always be asking
yourself are there any questions that
are not there for instance login screen
well what happens so I just gave you
those two scenarios you know happy path
login negative case still happy path
user logs in with invalid credentials is
kicked out but nowhere in those
requirements specifies hey what happens
if I get bad data or weird data or a SQL
command if you leave out things like
that it's not going to get coded you
potentially could leave yourself open
for problems or the feature is not going
to work as
expected so we have to ask ourselves
looking at a requirement for for
instance just a screen like I said the
login screen so you have two Fields you
have a username and password well from a
web perspective or even an application
perspective are they alpha numeric do
they allow special characters do any
input Fields these are things you should
ask uh is it uh numeric only can I allow
SQL should I look for specific commands
do I need to mask the data you know is
this data being stored into a database
do I need to set a max length a minimum
length do I have to add specific
criteria oh I need uppercase letters
lowercase letters I need numbers I need
special characters it has to be a
minimum of a certain length and if it's
not and they try to log in or they try
to create this
information what do we communicate to
the user that they've done wrong other
than oh hey you can't log in or oh hey
you can't create a password what do you
tell the user so you have to also think
about the error handling behind the
scenes as well as what is displayed to
the user so a simple login page hey
build me a login page to allow users to
log in sure sounds easy but there are so
many layers to unpack with that that
this is just one example of how to kind
of peel back the onion when you're
dealing with these type of situations
now a recent one we both uh were looking
at is we were trying to walk through the
requirements with a customer and we
started running across things that we
started realizing were muscle memory
these were things that the users were
doing that they weren't thinking about
so to them it just worked as it it's
supposed to but they weren't
communicating to us what it is that they
were doing and what it was that they
were expecting from the system or that
the system should do so when we go to
code this or work in a similar solution
without this things are going to break
people may not get paid you know
customers may not get their products on
time so you always have to look at the
little pieces you know you may have the
high level you know big road map site
map whatever but you need to pick at it
you need to literally get into those
nitty-gritty details and at the end of
the day if you think from a tester
perspective look at the use cases the
user stories for that given ticket and
if you can write every single user story
you can write those tests first then
write the code and then next time you go
to make a change to this if you break
one of those user stories you'll know
immediately the code will never make it
out the door and then you go back and
you have to fix it before introducing a
bug to the end user you know we don't
want to be like that one company that
took Microsoft down all across the world
so again these are those Psychopaths
those paths that you may not always look
at with your stories you have to get to
those details you have to talk to the
customers and sometimes you literally
just have to sit there and watch what
the end user does it may be boring as
heck but watch what they do they may do
what they say they do great record that
if they don't do what they say they do
stop them and find out why or just pay
attention and see what use case they
just introduced that has not been
communicated and finally the other thing
you want to look at when you're watching
that is are your end users or is the
prospective customer doing things
outside of the
system that again is that muscle memory
or a process they've introduced to work
with their current systems because their
systems don't do it so they have built a
system on top of a system that you have
to kind of unpack and figure out what
that psychopath is to put those
requirements into a ticket to make sure
that your functionality that this
software that you're building meets the
customer's demands
that is that last part is probably the
best is you can say tell me and you're
going to get something if you say show
me you will get something different a
lot particularly if you're dealing with
an existing system with a call them a
you know a power user or a a user that
has been on this for a long time because
as Michael said a lot of times they'll
have their own systems I've been at
places where they've got these huge
systems and they'll tell you that they
use them for everything and you sit down
in 2 seconds into it realize that
they've got Post-it notes or they've got
exra little spreadsheets they've got all
this stuff it's like well what is that
oh I use that so I can get this thing
and it's just it's the kind of stuff
you're like well wait a minute you said
you only use a system then what happens
if that's not there well that never
happens because I always sit down at my
desk and my Post-It note is always there
it's it's those kinds of things that you
need to you need to find a way to get to
it and sometimes you're not told it
because people want to tell you the
right way to to do it which is not the
real way that they do it and that's
where show me is so much more value
sitting down and this is I think lost a
lot when we have so many remote uh you
know engagements and stuff like that and
I was very frustrated in one not too
long ago where it's like it was third
and fourth hand information as opposed
to just being able to get boots on the
ground and watch somebody do it and how
they use the application and how they
use the
system and be able to actually say okay
what's actually going on because in this
case it's one of those you get to a
point where you say okay well how is
this getting used and they say they use
it like this I think it's like well wait
a minute you think if you don't know
then we need to go like who can say
definitively what the answer is now in a
very similar vein you can say
definitively what you think about us and
what your suggestions are for us by
sending us an email at info
developer.com you can contact us out on
developer.com on our contact form you
can put comments wherever you see us
whether it's out on YouTube and the
developer ner Channel whether it's out
on whatever your favorite podcasting
tool is uh or your actually podcast
listening device is all of that stuff
wherever it is leave us comments send us
com smoke signals we really don't care
however you get it to us we want to hear
from you we want that kind of feedback
because it helps us help you help us be
better building better developer
podcasters so we can help you build
better developers essentially that kind
of thing we are not done though we are
continuing this season we have tripped
at the 800 Mark apparently in number of
EP episodes which is in itself sort of
mind-boggling thinking back to like when
it went to like double digits it was
like wow I made it to 10 and now we're
quite a bit away from that so we're just
marching along we will come back with uh
more on the developer Journey next time
around until then go out there and have
yourself a great day a great week and we
will talk to you next
time bonus material uh I have quite a
bit so real quick so I try not to touch
on too much I try to keep
it on
track as we talked about watching your
users trying to figure out what they do
look at tools like snag it look at
QuickTime if you're on MacBooks use
recording tools do do anything you can
to capture what the user does while
they're doing it will help you immensely
figure out one what it is they're doing
two if the software works or not if
there's any bugs in the current system
that you need to avoid and three you
find out what they are not telling you
when they're doing what they're
doing that is that's a nice little
follow-up the best thing you can do
whether this goes for bug reporting too
people love to send you a screenshot and
it's like an error message and you
almost always are going up falling out
how did you get there and sometimes
they're going say I don't know but then
so then you're like okay well next time
you get to that try to remember what you
did so you can help me get to that uh
but recording stuff is huge I worked
with the company for a while that that
was one of the things they did all the
time so they would get bugs and the guy
that was effectively this is like one of
those it's a smaller company it's a guy
that's effectively the CIO would get on
calls with people and he would walk
through stuff so he could understand so
he could actually record the error or
the bug and then he would put that as
part of the ticket that went into the
system so whether and whether whoever it
was that got it could sit down and had
everything they needed to know on how to
reproduce it and he would you know he
could throw stuff in there comments like
this is what we should expect or we
should be able to see this thing and
sometimes even show you this is how it
should work this is the path they took
and it obviously doesn't work so
recording is huge not just don't trust
people actually even yourself when
you're doing this kind of stuff is like
what all did I do to get to that there's
times you can't remember either so the
more you record the more you can
actually watch and observe the better
that's all going to
be that will wrap this one up and we're
going to dive right back into our next
topic next time around for you depending
on when you're seeing this it may be a
couple of days or you could go bam right
into the next one that being said as
always feel free to leave us comments
leave us feedback we love to hear from
you however you want to engage with us
we're happy to do so whether you want to
continue doing this on YouTube or
whether you want to just listen to our
incredible voices while you're driving a
car exercising or something like that
always happy to do so we are uh always
looking for new topics next season we've
got some really cool stuff coming back
we've already talked about we sort of
threw some bonuses out a while back on
where we're going with that we'll
probably drop a hint or two again in
case you miss that one if not go back
and listen to every single prior episode
and maybe you'll find it somewhere
hidden in there little Easter egg that's
being said it's time for you to get out
there and get back to work and for us to
go figure out what we're going to talk
about next time so have yourself a great
one we'll talk to you later
[Music]