Detailed Notes
Welcome back to another episode of Building Better Developers. Today, we’re tackling an issue that every developer faces at some point: panic during software delivery. Whether it’s a critical bug or a new feature that isn’t functioning as expected, panic can strike anytime your software fails in the hands of a user. Rob and Michael cover handling software delivery panic with practical tips and real-life examples.
Read more: https://develpreneur.com/handling-software-delivery-panic-strategies-for-developers
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.
Transcript Text
[Music] hey everybody we're back um so we're thinking about what we're going to do today and I trying to remember if we had any I don't think we had anything particular uh topic wise that we wanted to cover this time around so is there something you got off the top of your head otherwise I'll think of something off the top of my head real quick not at the moment okay I think uh skins go something my rain into this week is the um basically it's a customer panic button and what happened I think I mentioned this is I had a customer that it's like you know hey you know go take a look at the site been working on it for a while it's essentially it's not like not a full demo but like a hey it's demo enough and this is the this one of those where it's like the primary guy that's got some technical knowledge it's not like the CEO or something like that it's somebody that you expect to have a little bit of although not a developer they have a little bit of understanding of software development and he does I mean there's no question about that but the first thing he did was he logged in and he went to do like one thing that was like and it was broken it was just like right off the bat and it was one of those it was because you know I'm used to it's got like 15 values you have to enter in and if you enter one of these wrong then it throws it into the I'm not going to show it to you pile basically because we you know we're in flight and there's some stuff there that it's basically saying oh that's Legacy data so we're not going to show you that right now and so he goes and he creates this record it doesn't show up on the list he panics he's like oh my God it doesn't work at all and I guess in his you know in his defense it didn't because he was blocked it was like as soon as he did that he can't move forward and then he's also using you know some old data and so it's you know Panic ensues and I think that's something that I've seen it often enough where it's like you put it out there and somebody takes a look at it and it's like bam first thing they do is they do something different that breaks it and then it's just like all right doesn't work at all you it's like it's a showstopper and even if you you know it works you've run through it you know but it's like it's a showstopper for them so I think that's a handling those situations what do you do to first to call them and then to you know essentially go into a little bit of firefighting mode to do a little triage to make sure that figure out what they're doing and and get moving forward does that sound like a cool or at least a topic for the first part yeah so we're going to focus more on completed code going out running into issues or proof of Concepts going out with incorrect expectations causing the firefighter or um this would be probably both but it's really more the latter because it's really more this is where it's like we haven't fully where you know there are issues so this is beta software kind of stuff this is where you know there's some issues you know there's a couple things going on you're not expect it's not should not be expected to be 100% and literally the customer is like I know it's got bugs I know you're still working through stuff it's like okay so we're on the same page but we're not on the same page so it's dealing with those kinds of situations because I think if you're if you're new to this if you haven't handled it before then like panic and sues on your side as well because then you're s and and I've been in those where it's like shoot that should work and the next thing you know your head's down trying to figure out how to fix that one bug particularly if it occurs like in a meeting or something because then it's like all right now I'm totally focused on this bug as opposed to maybe something better that you could be doing with that that project or that application so I'll sort of like I'll set the table and then throw it to you and see what your thoughts are on it and how you would handle it because I think it's it'll be another one of those I'll sort of be like here's what happened here's my thoughts or here's how I handle it and then throw it to you for the followup cool yeah it's kind of funny because this if we think back to American own patient that was Jeff anytime you see your C son he would the first thing he would do is go break it yeah it's like like I said I've seen those people before now I was thinking Jeff was one of those some people are gifted like that they like they can break it because they don't do it the same way the developers do and I don't want to I don't want to yeah right out of the the um the podcast section so yeah we'll into that and we we'll talk about that as well the magic people that are out there hello and welcome back we are diving into yet another episode of our podcast it is building better developers it is develop andur it was originally it's develop or became building develop better developers because the lady in the box also known as Alexa uh does not recognize developing or very well if you say hey play the next episode of that however if you do say play the next so to building better developers she will pop right up if I were to say that right now she might even be so sensitive that she would fire that off wherever your room is so just so you know that being said my name is Rob Broadhead I am a founder of develop andur also a founder of RB Consulting and uh we've just been cruising through however many we're up to now 700 plus episodes on the other side of the digital divide is my friend Michael I'll let you introduce yourself hey everyone my name is Michael Mage I'm another co-founder of developing ER and I'm also a founder of Invision QA this episode I don't want to hang you have you hanging on too long this episode we're gonna talk about Panic basically this is uh really not an uncommon thing uh probably unfortunately but it's something that very workable it's something you can work with that you can handle and make the Panic not be a horrible thing and this pan is when you are delivering software usually now obviously if it's 100% like we've tested it this should be bulletproof and somebody breaks it and panic ensues okay it's probably a little bit more panic because that means you didn't you didn't QA right or they're doing something completely different that has you know new and it should not be new at this point we'll talk about that a little bit but if it's a beta or something like that there are these people and sort of precede it with this is there some people are just gifted at breaking stuff you can deliver your you can test it as thoroughly as you think you can you put your software out there two minutes later they give you an email back and say hey I can't make this work this is just broken and I've run across several people like this uh usually QA people are that's like where they end up because that's their gift that's what they do best but sometimes it's going to be your manager it's going to be your it could be a CEO it could be whoever it is and it's usually somebody you don't want it to be because you just gave them something that should work and they basically responded right away it doesn't and the Panic is usually when you send it out they should be you know maybe testing like it's a beta product they should be testing it and it is a non it's a non-starter for them they have hit a roadblock it is something where they cannot move forward and I mention this because I had this just the other day with a customer who is it's not like this is somebody that is not technically knowledgeable I mean they're not a developer but they understand the software process they understand how these things go so I'm like hey you can have an alpha version of it start banging around a little bit right away he gets to a showstopper little bit of a and I didn't you know I'm in a call with him and he's like yeah I couldn't get this to work and so there is a little bit of that panic because it's like now okay he and he was he was like this isn't going to work at all there's no way we're like I can't imagine that you're anywhere close to end of this thing being done none of it works none of it looks right all this kind of stuff and all of that was and even he during this was saying you know I know we haven't really like focused on the design I know we haven't really focused I know there's bugs and things like that but because he's blocked he's panicked because he's like all right now this this doesn't work at all it goes from you know in his mind it goes from We're 95% there or 90% there or something like that to we're not anywhere close those are the kinds of things we panic sets in and if you are especially if you're a consultant uh you know you're working with a customer or if your employee and your manager is is hitting this situation Panic can ensue on your end because now you're like oh crap I got to fix this like right away now two things one don't panic say take a step back take a deep breath first thing you want to do is get the situation that they went into to break it because sometimes it's as simp as oh I didn't get your user ID set up with the right permission or oh you can't set that value because this other thing's going on or oh by the way yeah you did that but that should never happen because we discussed it because it's in the requirements it doesn't happen that way we have it allowed because you're an admin you know or something like that and sometimes it is a bug sometimes it's like oh yeah that's right you don't see that or that value is not there and it's just matter of in my testing in my development mindset I missed it I didn't think about somebody entering that value at that point or I didn't realize that you could enter that value take that into advisement say okay cool take a note I will fix that I will handle that and then do so because they found it you want to be you do want to prioritize that a little bit is make sure that that gets addressed particularly before you cut them loose on the the application again if it's something you can fix right there maybe but be careful about rabbit holes because I have been in more especially like if you're demoing something and you're on a demo and it breaks right there because somebody says hey why don't can you try this and you're like oh sure I can try that because this works great and then it blows up one don't ever say yes I can try that because like if you haven't gone through your if you're not sticking to your script in a demo you're going to have problems this trust me there just I don't care how good you think the software is is there is a magic about people saying hey can you enter this value can you do this real quick in a demo and it breaks everything and if you try to fix it inevitably you're going to break everything so now you can't even get back to the working state that you had right before you got into the demo so don't panic you know what level of trustworthiness your your software is at if it's crap okay it's like yeah I know it's full of bugs it's like here's this we have one happy path and if you vary from it it will break okay just make sure you're clear to that but if it's something where it's like hey we're mostly there but we still have bugs understand that okay this person it's basically thank you you just found a bug I'll knock that out put it on my list and move on if they're panicking feel free to like you know especially if they're they go from we think this is almost there to this is not even close and we're going to bail you know we're going to bail out on the project I guess it' be the worst possible thing it's like okay we're done we're not even going to talk to you anymore take a deep breath say hey let me show you where this does work let me walk you through it instead of you walking through it because obviously they found some broken stuff say hey let me just alleviate some fears I'm going to walk you through this and show you that it does work and that will help alleviate those fears and help people from panicking and overreacting now that's just it in a nutshell I want to throw it over to Michael because he's been like snickering along the way as well and see what your thoughts are in these kinds of situations because I also know you have experienced more than a couple of them thank you rob yeah uh plenty of situations like that um one particular came to mind and we briefly touched on it before we kicked off the podcast was uh we actually worked together at a place where no matter what we did we could try to test our code the moment we said the code was ready boss would go out and within minutes oh I found a bug and it's like what did you do um so there was always that constant anxiety to hit that button to say the code is done it it's committed uh and things are good which actually led me down a interesting path of my career over that because um prior to that in college I went through a lot of classes that actually push test driven development and early on a lot of companies and a lot of developers don't follow that model because really a lot of people think well if I write my code the code performs there's my test the code works and in a way sure but we still need to write our unit test we still need to have some type of QA around our applications however if you go into the mindset of a requirement or an application that you're putting out with testing first in fact I actually did that this week I had a ticket come across that was fairly well documented with the requirements but there was kind of a few missing pieces so I had to go back ask some more questions uh kind of refine the requirements first but then I literally started with a main method and started stepping through okay what is the final output what is is supposed to generate so I created my pojo to generate the or I'm sorry the dto to generate the uh output from the API call so I had a little hardcoded U Json script that kicked back out into this call and produced a dto and then I slowly walked through all the steps so by the time I was done I literally had 15 methods each method was a specific requirement point it did a specific task easily to test and when I was done testing was mute I all I had to do is literally write 15 unit tests to test my methods done and then write a couple integration tests to test the software now in Rob situation where he was talking about this I I've run into a lot of situations especially with new clients or even Prospect clients where it's like hey I have this problem I need this application or I'm looking to have this done so what you do is you and you mock something up you throw something together that's you know on rubber bands Sho strings and duct tape to just kind of present what it will do the problem is especially in Enterprise if you show it to the wrong person they think oh this is great it's going to production tomorrow and you're like oh no no um there there's and then you end up in these weird coding situations where you're struggling uh 400 you know 200 hours trying to get something out the door that the big wig thinks was ready yesterday and it's not so they kind of a flip to where they went from high level of hey we're ready to go to you know no confidence in the project in this situation you went from hey even though this doesn't look uh you know isn't fully functional you demoed something that looked functional enough and they're already going to production so now you're struggling to fill those holes and gaps to avoid the downfall that could be coming and the testing is a good point on that uh because that is one of the one of the things you can do to help you know to make a make lemonade out of the the lemons of a situation like this is to talk to them about how did you generate this issue how did this come about particularly if you're further into your your software development life cycle where this should be a fairly mature product and I've run into this as well where I've got a I've got another customer that it's a fairly mature product but it is it's amazing and he's in the QA world uh he's very good at breaking some and he's got a couple of employees that are very good at like they just they always do stuff different or different enough that it breaks the system and so what you do is you find out what they did if you can you know these days you can maybe have them recorded or something like that is just like figure out those steps and then build that into your tests so for example this this application I just talked about one of the things we do is we've got a basically selenium based robot that runs through the whole site and does a whole bunch of stuff to go check different things out look at variables make sure things are are working right it's it's like a smoke test maybe a little deeper than that but it's just really so when we go deploy something kick this thing off hit all these different pages look at all the results let's make sure everything's working still and then if we've got like over time as they've said oh hey we did this and this broke then we have specific we just add that in so now we test and we'll go work look at that specific thing and say okay I'm going to do this action and it better come back correctly a something I learned back in college with some of these kinds of things the special stuff um is we had a guy and I will never forget his last name his last name was ens shank and the way it was spelled actually broke everybody's sort we had something that you were supposed to go in and you're sorting and name or string based by uh just alphabetical order and the P the and the pattern that we went through the sort that we did and I can't remember which one it was but it assumed a certain thing it a certain it assumed a certain order of letters we didn't realize that until we actually hit it and realized it was like an i before e instead of E before I or something like that I can't remember what it was but it was something to that level that only certain words and his name happened to be one of those words would break it and the test was you put your name into it and this guy was like the smartest guy in the class and he would run through and he could not get this thing to work and finally like dragg the rest of us in we all figured it out and went through it but it was because everybody else's worked because their name didn't have that little magic problem and that's so often what happens with an application is that they take one step different or they set one value different and that's the one that the combination of things then breaks it and it's a matter of find out what that step is reproduce it and then you should be able to figure out why is it that their specific series of steps they took caused a break when yours did not and so it is a again something it can be yes sort of uncomfortable at the moment because people are like this doesn't work at all and you're sort of stuck trying to figure out how to fix it but if you step back and say okay it's a bug software has that let's just go with that I'm going to go figure out what it did fix it and then you can show them the next time around and it helps build confidence to say hey this is what you did we didn't catch this and maybe you can show three other flavors of that that process or that approach that would have broken it but it's like hey look we can catch this and this and this and this and build that confidence back up and that's Sometimes the best thing is to say it's it's not just that you because I think people don't some people expect you to have 100% perfect software out of the gates it's not going to happen but a lot of people realize there's going to be some bugs and things like that there's going to be issues there's G to be changes if you can respond quickly and in a you know a logical Manner and say hey here's what was going on here's what we changed this is how it's been improved then a lot of times that is going to be the big win coming out of it uh final thoughts on that before we wrap this one up yeah one additional things especially with what you kind of experienced to kind of point out when you're working on code or tickets or requirements some things to think about as you're before you even pick up the ticket or start the work one do you have enough requirements do you have enough Define to work the problem for instance if it's user inputs do you have the men Max is it alpha numeric is it Alpha only can it take special characters Common Sense questions that kind of want to Define before you start writing because that will impact the user experience one other thing to think about is not just from the user side but also what are the uh the um basically the user acceptance criteria what you know if I complete this ticket how do I test it what is acceptable for completion you know what the minimum level of completion and then lastly make sure you add enough debuggers or comments in your code so that if an exception or a problem does occur it gets logged properly so you're not having to dig through the code to figure out where the heck something went wrong that is actually where a lot of times I've found that is that I found that you know customer has a problem I can't track it down and so we add some logging around that like maybe it's a process that we thought wasn't going to fail or code that were like oh that's going to work every time oh wait no it doesn't because they just broke somewhere in there so sometimes that's where you you know add exception handling logging things like that U anything that you can use to help you with debugging it is always going to be helpful as well because it's just like down the road you can say okay we know that this section of code at least is is logging the things that it needs to for us to be able to debug it outside of the you know outside of actually doing that that action outside of like being on the server and of course depending on your application sometimes that's easier said than done uh sometimes you can get more information out of your server sometimes you can't all of that it's uh you know take that on a case-by Case basis that being said we're going to take this uh minute by minute on a case-by Case basis and the case right now is to wrap this sucker up so we are going to come back we're not done yet with our season we're going to continue to talk through some of the just the challenges and the experiences that we have each week some of the technology that we're running into if you have any questions comments or anything like that or suggestions recommendations give us a shoot us an email at info developer.com check us out on developer.com um you''ve got a comment page contact us you can check us out on our YouTube channel you can check it out check us out at develop andur on Twitter SLX you name it we're out there somewhere and if not let us know and we'll go get out there so you can contact us there you just got a contact us on a different thing chicken and egg problem that being said go out there and have yourself a great day a great week and we will talk to you next time the rest of you we're going to continue to talk to you as we wrap this one up and then cut into figure out what we're going to do with our next episode around uh any extra bonus thoughts on that actually yeah so as you were wrapping up it just dawned on me um we didn't talk about tools so as you're running into these problems or you're working on software look at using tools like sonar L sonar ke uh code debuggers um these are very useful tools to help you identify areas of risk within your code potential uh dependency issues or even uh risk for like SQL injections things of that nature the other thing to think of is to also maybe do like an OAS vulnerability check to see if there's any dependencies that your software might be using that also potentially could have bugs because if you use thirdparty plugin the bug may not be you it might be someone else and then you've got to go down a whole different Rabbit Hole to fix your coat yeah I would I would add on yeah I think if you don't use static code analysis tools then uh it's very good to add it's built in there's actually a lot of them built into most of the modern IDE but go if you're not really comfortable about if you don't know if they're being used go just pick your favorite search engine do uh static static code analysis tools for whatever your language is you know Java python net whatever and you will find some uh a lot of them are going to be the same that you're going to see it's going to be the same name sort of like you have like log for J log for n all those it's one of those you're going to see it for whatever your language is and then once you can get an idea of what is out there then it'll be very helpful there's also uh there's things you can tag attach into your uh your GitHub rep your git repositories and do some stuff there you can build it into your if you have like a your devop structure some of those things you can use testing you can do static code analysis as well it is at least at the same level I think as particularly unit tests and things like that I've actually found it's probably more useful and it's actually useful to better understand the language I don't know how many times that I've run an a static analysis thing across a language that I've been using sometimes even for a while and it will bring up some stuff and say hey you should try this or you should do that or this isn't used anymore or this is going to be deprecated and maybe you have a language doesn't you don't realize that's going to be deprecated or you don't realize there's a better newer way to handle that process and like Michael implied it's going to give you a lot of times Insight of things like hey if you do this you could be susceptible to some sort of a an attack or if you do this you're probably GNA have some logic issue it's things like that that you usually will not catch in a compile you know in quotes a compile run but you will catch once you start shoving data through there and it's really helpful for interpreted languages like a you know like a python or something like that and even PHP uh I found that there's a lot of times those things will catch stuff before you get it in a you know actually out in a live environment and it just speeds up the debug the test fix cycle that being said looks like you got one more thing to say so I'm G to let you say one more thing yeah in addition to all of that look at the tools that you're using a lot of the applications or Frameworks now have U user input functionality so like if you have an input field you can add oh this is alpha numeric oh it's min max characters so if you're doing anything especially front end or user facing make sure that you are looking at those inputs and applying the correct um configuration to those components as you're putting them out there it'll make your life so much easier if you do it right as you're doing it versus trying to do it on the back end agreed um it's just again it's always one of those the sooner you catch stuff and address it the you know the the less it's going to cost you in recoding it and making those changes so we wrap this one up and we will talk to you guys next time around leave com comments notes all that kind of good stuff uh we will have show notes probably for some of this I think we'll try to get some of the links in the show notes for a couple of the static analysis tools uh just to help you out and uh we will be back next time around [Music]
Transcript Segments
[Music]
hey everybody we're back um so we're
thinking about what we're going to do
today and I trying to remember if we had
any I don't think we had anything
particular uh topic wise that we wanted
to cover this time around so is there
something you got off the top of your
head otherwise I'll think of something
off the top of my head real
quick not at the
moment okay I think uh skins go
something my rain into this week is
the um basically it's a customer panic
button and what happened I think I
mentioned this is I had a customer that
it's like you know hey you know go take
a look at the
site been working on it for a while it's
essentially it's not like not a full
demo but like a hey it's demo enough and
this is the this one of those where it's
like the primary guy that's got some
technical knowledge it's not like the
CEO or something like that it's somebody
that you expect to have a little bit of
although not a developer they have a
little bit of understanding of software
development and he does I mean there's
no question about that but the first
thing he did was he logged in and he
went to do like one thing that was like
and it was broken it was just like right
off the bat and it was one of those it
was because you know I'm used to it's
got like 15 values you have to enter in
and if you enter one of these wrong then
it throws it into the I'm not going to
show it to you pile basically because we
you know we're in flight and there's
some stuff there that it's basically
saying oh that's Legacy data so we're
not going to show you that right now and
so he goes and he creates this record it
doesn't show up on the list he panics
he's like oh my God it doesn't work at
all
and I guess in his you know in his
defense it didn't because he was blocked
it was like as soon as he did that he
can't move forward and then he's also
using you know some old data and so it's
you know Panic ensues and I think that's
something that I've seen it often enough
where it's like you put it out there and
somebody takes a look at it and it's
like bam first thing they do is they do
something different that breaks it and
then it's just like all right doesn't
work at all you it's like it's a
showstopper and even if you you know it
works you've run through it you know but
it's like it's a showstopper for them so
I think that's a handling those
situations what do you do to first to
call them and then to you know
essentially go into a little bit of
firefighting mode to do a little triage
to make sure that figure out what
they're doing and and get moving forward
does that sound like a cool or at least
a topic for the first part yeah so we're
going to focus more
on completed code going out running into
issues or proof of Concepts going out
with incorrect expectations causing the
firefighter or um this would be probably
both but it's really more the latter
because it's really more this is where
it's like we haven't fully where you
know there are issues so this is beta
software kind of stuff this is where you
know there's some issues you know
there's a couple things going on you're
not expect it's not should not be
expected to be 100% and literally the
customer is like I know it's got bugs I
know you're still working through stuff
it's like okay so we're on the same page
but we're not on the same page so it's
dealing with those kinds of situations
because I think if
you're if you're new to this if you
haven't handled it before then like
panic and sues on your side as well
because then you're s and and I've been
in those where it's like shoot that
should work and the next thing you know
your head's
down trying to figure out how to fix
that one bug particularly if it occurs
like in a meeting or something because
then it's like all right now I'm totally
focused on this bug as opposed to maybe
something better that you could be doing
with that that project or that
application so I'll sort of like I'll
set the table and then throw it to you
and see what your thoughts are on it and
how you would handle it because I think
it's it'll be another one of those I'll
sort of be like here's what happened
here's my thoughts or here's how I
handle it and then throw it to you for
the followup
cool yeah it's kind of funny because
this if we think back to American own
patient that was Jeff anytime you see
your C son he would the first thing he
would do is go break it yeah it's like
like I said I've seen those people
before now I was thinking Jeff was one
of those some people are gifted like
that they like they can break it because
they don't do it the same way the
developers do and I don't want to I
don't want to yeah right out of the the
um the podcast section so yeah we'll
into that and we we'll talk about that
as well the magic people that are out
there hello and welcome back we are
diving into yet another episode of our
podcast it is building better developers
it is develop andur it was originally
it's develop or became building develop
better developers because the lady in
the box also known as
Alexa uh does not recognize developing
or very well if you say hey play the
next episode of that however if you do
say play the next so to building better
developers she will pop right up if I
were to say that right now she might
even be so sensitive that she would fire
that off wherever your room is so just
so you know that being said my name is
Rob Broadhead I am a founder of develop
andur also a founder of RB Consulting
and uh we've just been cruising through
however many we're up to now 700 plus
episodes on the other side of the
digital divide is my friend Michael I'll
let you introduce yourself
hey everyone my name is Michael Mage I'm
another co-founder of developing ER and
I'm also a founder of Invision
QA this episode I don't want to hang you
have you hanging on too long this
episode we're gonna talk about Panic
basically this is uh really not an
uncommon thing uh probably unfortunately
but it's something that very workable
it's something you can work with that
you can handle and make the Panic not be
a horrible thing and this pan is when
you are delivering software usually now
obviously if it's 100% like we've tested
it this should be bulletproof and
somebody breaks it and panic ensues okay
it's probably a little bit more panic
because that means you didn't you didn't
QA right or they're doing something
completely different that has you know
new and it should not be new at this
point we'll talk about that a little bit
but if it's a beta or something like
that there are these people and sort of
precede it with this is there some
people are just gifted at breaking stuff
you can deliver your you can test it as
thoroughly as you think you can you put
your software out there two minutes
later they give you an email back and
say hey I can't make this work this is
just broken and I've run across several
people like this uh usually QA people
are that's like where they end up
because that's their gift that's what
they do best but sometimes it's going to
be your manager it's going to be your it
could be a CEO it could be whoever it is
and it's usually somebody you don't want
it to be because you just gave them
something that should work and they
basically responded right away it
doesn't and the Panic is usually when
you send it out they should be you know
maybe testing like it's a beta product
they should be testing it and it is a
non it's a non-starter for them they
have hit a roadblock it is something
where they cannot move forward and I
mention this because I had this just the
other day with a customer who is it's
not like this is somebody that is not
technically knowledgeable I mean they're
not a developer but they understand the
software process they understand how
these things go so I'm like hey you can
have an alpha version of it start
banging around a little bit right away
he gets to a
showstopper little bit of a and I didn't
you know I'm in a call with him and he's
like yeah I couldn't get this to work
and so there is a little bit of that
panic because it's like now okay he and
he was he was like this isn't going to
work at all there's no way we're like I
can't imagine that you're anywhere close
to end of this thing being done none of
it works none of it looks right all this
kind of stuff and all of that was and
even he during this was saying you know
I know we haven't really like focused on
the design I know we haven't really
focused I know there's bugs and things
like that but because he's blocked he's
panicked because he's like all right now
this this doesn't work at all it goes
from you know in his mind it goes from
We're 95% there or 90% there or
something like that to we're not
anywhere
close those are the kinds of things we
panic sets in and if you are especially
if you're a consultant uh you know
you're working with a customer or if
your employee and your manager is is
hitting this situation Panic can ensue
on your end because now you're like oh
crap I got to fix this like right
away now two things one don't panic say
take a step back take a deep breath
first thing you want to do is get the
situation that they went into to break
it because sometimes it's as simp as
oh I didn't get your user ID set up with
the right permission or oh you can't set
that value because this other thing's
going on or oh by the way yeah you did
that but that should never happen
because we discussed it because it's in
the requirements it doesn't happen that
way we have it allowed because you're an
admin you know or something like that
and sometimes it is a bug sometimes it's
like oh yeah that's right you don't see
that or that value is not there
and it's just matter of in my testing in
my development mindset I missed it I
didn't think about somebody entering
that value at that point or I didn't
realize that you could enter that value
take that into advisement say okay cool
take a note I will fix that I will
handle that and then do so because they
found it you want to be you do want to
prioritize that a little bit is make
sure that that gets addressed
particularly before you cut them loose
on the the application again if it's
something you can fix right there maybe
but be careful about rabbit holes
because I have been in more especially
like if you're demoing something and
you're on a demo and it breaks right
there because somebody says hey why
don't can you try this and you're like
oh sure I can try that because this
works great and then it blows up one
don't ever say yes I can try that
because like if you haven't gone through
your if you're not sticking to your
script in a demo you're going to have
problems this trust me there just I
don't care how good you think the
software is is there is a magic about
people saying hey can you enter this
value can you do this real quick in a
demo and it breaks everything and if you
try to fix it inevitably you're going to
break everything so now you can't even
get back to the working state that you
had right before you got into the demo
so don't panic you know what level of
trustworthiness your your software is at
if it's crap okay it's like yeah I know
it's full of bugs it's like here's this
we have one happy path and if you vary
from it it will break okay just make
sure you're clear to that but if it's
something where it's like hey we're
mostly there but we still have bugs
understand that okay this person it's
basically thank you you just found a bug
I'll knock that out put it on my list
and move on if they're panicking feel
free to like you know especially if
they're they go from we think this is
almost there to this is not even close
and we're going to bail you know we're
going to bail out on the project I guess
it' be the worst possible thing it's
like okay we're done we're not even
going to talk to you anymore
take a deep breath say hey let me show
you where this does work let me walk you
through it instead of you walking
through it because obviously they found
some broken stuff say hey let me just
alleviate some fears I'm going to walk
you through this and show you that it
does work and that will help alleviate
those fears and help people from
panicking and
overreacting now that's just it in a
nutshell I want to throw it over to
Michael because he's been like
snickering along the way as well and see
what your thoughts are in these kinds of
situations because I also know you have
experienced more than a couple of
them thank you rob
yeah uh plenty of situations like that
um one particular came to mind and we
briefly touched on it before we kicked
off the podcast was uh we actually
worked together at a place where no
matter what we did we could try to test
our code the moment we said the code was
ready boss would go out and within
minutes oh I found a bug and it's like
what did you do um so there was always
that constant anxiety to hit that button
to say the code is done it it's
committed uh and things are good which
actually led me down a interesting path
of my career over that because um prior
to that in college I went through a lot
of classes that actually push test
driven development and
early on a lot of companies and a lot of
developers don't follow that model
because really a lot of people think
well if I write my code the code
performs there's my test the code
works and in a way sure but we still
need to write our unit test we still
need to have some type of QA around our
applications however if you go into the
mindset of a requirement or an
application that you're putting out with
testing first in fact I actually did
that this week I had a ticket come
across that was
fairly well documented with the
requirements but there was kind of a few
missing pieces so I had to go back ask
some more questions uh kind of refine
the requirements first but then I
literally started with a main method and
started stepping through okay what is
the final output what is is supposed to
generate so I created my pojo to
generate the or I'm sorry the dto to
generate the uh output from the API call
so I had a little hardcoded U Json
script that kicked back out into this
call and produced a dto and then I
slowly walked through all the steps so
by the time I was done I literally had
15 methods each method was a specific
requirement point it did a specific task
easily to test and when I was done
testing was mute I all I had to do is
literally write 15 unit tests to test my
methods done and then write a couple
integration tests to test the software
now in Rob situation where he was
talking about this I I've run into a lot
of situations especially with new
clients or even Prospect clients where
it's like hey I have this problem I need
this application or I'm looking to have
this done so what you do is you and you
mock something up you throw something
together that's you know on rubber bands
Sho strings and duct tape to just kind
of present what it will do the problem
is especially in Enterprise if you show
it to the wrong person they think oh
this is great it's going to production
tomorrow and you're like oh no no um
there there's and then you end up in
these weird coding situations where
you're struggling uh 400 you know 200
hours trying to get something out the
door that the big wig thinks was ready
yesterday and it's not so they kind of a
flip to where they went from high level
of hey we're ready to go to you know no
confidence in the project in this
situation you went from hey even though
this doesn't look uh you know isn't
fully functional you demoed
something that looked functional enough
and they're already going to production
so now you're struggling to fill those
holes and gaps to avoid the downfall
that could be coming
and the testing is a good point on that
uh because that is one of the one of the
things you can do to help you know to
make a make lemonade out of the the
lemons of a situation like this is to
talk to them about how did you generate
this issue how did this come about
particularly if you're further into your
your software development life cycle
where this should be a fairly mature
product and I've run into this as well
where I've got a I've got another
customer that it's a fairly mature
product but it is it's amazing and he's
in the QA world uh he's very good at
breaking some and he's got a couple of
employees that are very good at like
they just they always do stuff different
or different enough that it breaks the
system and so what you do is you find
out what they did if you can you know
these days you can maybe have them
recorded or something like that is just
like figure out those steps and then
build that into your tests so for
example this this application I just
talked about one of the things we do is
we've got a basically selenium
based robot that runs through the whole
site and does a whole bunch of stuff to
go check different things out look at
variables make sure things are are
working right it's it's like a smoke
test maybe a little deeper than that but
it's just really so when we go deploy
something kick this thing off hit all
these different pages look at all the
results let's make sure everything's
working still and then if we've got like
over time as they've said oh hey we did
this and this broke then we have
specific we just add that in so now we
test and we'll go work look at that
specific thing and say okay I'm going to
do this action and it better come back
correctly a something I learned back in
college with some of these kinds of
things the special stuff um is we had a
guy and I will never forget his last
name his last name was ens shank and the
way it was
spelled actually broke everybody's sort
we had something that you were supposed
to go in and you're sorting and name or
string based by uh just alphabetical
order and the P the and the pattern that
we went through the sort that we did and
I can't remember which one it was but it
assumed a certain thing it a certain it
assumed a certain order of letters we
didn't realize that until we actually
hit it and realized it was like an i
before e instead of E before I or
something like that I can't remember
what it was but it was something to that
level that only certain words and his
name happened to be one of those words
would break it and the test was you put
your name into it and this guy was like
the smartest guy in the class and he
would run through and he could not get
this thing to work and finally like
dragg the rest of us in we all figured
it out and went through it but it was
because everybody else's worked because
their name didn't have that little magic
problem and that's so often what happens
with an application is that they take
one step different or they set one value
different and that's the one that the
combination of things then breaks it and
it's a matter of find out what that step
is reproduce it and then you should be
able to figure out why is it that their
specific series of steps they took
caused a break when yours did not and so
it is a again something it can be yes
sort of uncomfortable at the moment
because people are like this doesn't
work at all and you're sort of stuck
trying to figure out how to fix it but
if you step back and say okay it's a bug
software has that let's just go with
that I'm going to go figure out what it
did fix it and then you can show them
the next time around and it helps build
confidence to say hey this is what you
did we didn't catch this and maybe you
can show three other flavors of that
that process or that approach that would
have broken it but it's like hey look we
can catch this and this and this and
this and build that confidence back up
and that's Sometimes the best thing is
to say it's
it's not just that you because I think
people don't some people expect you to
have 100% perfect software out of the
gates it's not going to happen but a lot
of people realize there's going to be
some bugs and things like that there's
going to be issues there's G to be
changes if you can respond quickly and
in a you know a logical Manner and say
hey here's what was going on here's what
we changed this is how it's been
improved then a lot of times that is
going to be the big win coming out of it
uh final thoughts on that before we wrap
this one up yeah one additional things
especially with what you kind of
experienced to kind of point out when
you're working on code or tickets or
requirements some things to think about
as you're before you even pick up the
ticket or start the work one do you have
enough requirements do you have enough
Define to work the problem for instance
if it's user inputs do you have the men
Max is it alpha numeric is it Alpha only
can it take special characters Common
Sense questions that kind of want to
Define before you start writing because
that will impact the user
experience one other thing to think
about is not just from the user side but
also what are the uh the um
basically the user acceptance criteria
what you know if I complete this ticket
how do I test it what is acceptable for
completion you know what the minimum
level of completion and then lastly make
sure you add enough debuggers or
comments in your code so that if an
exception or a problem does occur it
gets logged properly so you're not
having to dig through the code to figure
out where the heck something went
wrong that is actually where a lot of
times I've found that is that I found
that you know customer has a problem I
can't track it down and so we add some
logging around that like maybe it's a
process that we thought wasn't going to
fail or code that were like oh that's
going to work every time oh wait no it
doesn't because they just broke
somewhere in there so sometimes that's
where you you know add exception
handling logging things like that U
anything that you can use to help you
with debugging it is always going to be
helpful as well because it's just like
down the road you can say
okay we know that this section of code
at least is is logging the things that
it needs to for us to be able to debug
it outside of the you know outside of
actually doing that that action outside
of like being on the server and of
course depending on your application
sometimes that's easier said than done
uh sometimes you can get more
information out of your server sometimes
you can't all of that it's uh you know
take that on a case-by Case basis that
being said we're going to take this uh
minute by minute on a case-by Case basis
and the case right now is to wrap this
sucker up so we are going to come back
we're not done yet with our season we're
going to continue to talk through some
of the just the challenges and the
experiences that we have each week some
of the technology that we're running
into if you have any questions comments
or anything like that or suggestions
recommendations give us a shoot us an
email at info developer.com check us out
on developer.com um you''ve got a
comment page contact us you can check us
out on our YouTube channel you can check
it out check us out at develop andur on
Twitter SLX you name it we're out there
somewhere and if not let us know and
we'll go get out there so you can
contact us there you just got a contact
us on a different thing chicken and egg
problem that being said go out there and
have yourself a great day a great week
and we will talk to you next
time the rest of you we're going to
continue to talk to you as we wrap this
one up and then cut into figure out what
we're going to do with our next episode
around uh any extra bonus thoughts on
that actually yeah so as you were
wrapping up it just dawned on me um we
didn't talk about tools so as you're
running into these problems or you're
working on software look at using tools
like sonar L sonar ke
uh code debuggers um these are very
useful tools to help you identify areas
of risk within your code potential uh
dependency issues or even uh risk for
like SQL injections things of that
nature the other thing to think of is to
also maybe do like an OAS vulnerability
check to see if there's any dependencies
that your software might be using that
also potentially could have bugs because
if you use thirdparty plugin the bug may
not be you it might be someone else and
then you've got to go down a whole
different Rabbit Hole to fix your coat
yeah I would I would add on yeah I
think if you don't use static code
analysis tools then uh it's very good to
add it's built in there's actually a lot
of them built into most of the modern
IDE but go if you're not really
comfortable about if you don't know if
they're being used go just pick your
favorite search engine do uh static
static code analysis tools for
whatever your language is you know Java
python net whatever and you will find
some uh a lot of them are going to be
the same that you're going to see it's
going to be the same name sort of like
you have like log for J log for n all
those it's one of those you're going to
see it for whatever your language is and
then once you can get an idea of what is
out there then it'll be very helpful
there's also uh there's things you can
tag attach into your uh your GitHub rep
your git
repositories and do some stuff there you
can build it into your if you have like
a your devop structure some of those
things you can use testing you can do
static code analysis as well it is at
least at the same level I think as
particularly unit tests and things like
that I've actually found it's probably
more useful and it's actually useful to
better understand the language I don't
know how many times that I've run an a
static analysis thing across a language
that I've been using sometimes even for
a while and it will bring up some stuff
and say hey you should try this or you
should do that or this isn't used
anymore or this is going to be
deprecated and maybe you have a language
doesn't you don't realize that's going
to be deprecated or you don't realize
there's a better newer way to handle
that process and like Michael implied
it's going to give you a lot of times
Insight of things like hey if you do
this you could be susceptible to some
sort of a an attack or if you do this
you're probably GNA have some logic
issue it's things like that that you
usually will not catch in a compile you
know in quotes a compile run but you
will catch once you start shoving data
through there and it's really helpful
for interpreted languages like a you
know like a python or something like
that and even PHP uh I found that
there's a lot of times those things will
catch stuff before you get it in a you
know actually out in a live environment
and it just speeds up the debug the test
fix
cycle that being said looks like you got
one more thing to say so I'm G to let
you say one more thing yeah in addition
to all of that look at the tools that
you're using a lot of the applications
or Frameworks now have U user input
functionality so like if you have an
input field you can add oh this is alpha
numeric oh it's min max characters so if
you're doing anything especially front
end or user facing make sure that you
are looking at those inputs and applying
the correct um configuration to those
components as you're putting them out
there it'll make your life so much
easier if you do it right as you're
doing it versus trying to do it on the
back
end agreed um it's just again it's
always one of those the sooner you catch
stuff and address it the you know the
the less it's going to cost you in
recoding it and making those changes so
we wrap this one up and we will talk to
you guys next time around leave com
comments notes all that kind of good
stuff uh we will have show notes
probably for some of this I think we'll
try to get some of the links in the show
notes for a couple of the static
analysis tools uh just to help you out
and uh we will be back next time around
[Music]