Detailed Notes
Welcome, today we are going to be talking about one of the most talked-about, but overlooked discussions about software and that is technical support. What do we do when software has a problem? In today's discussion, we're going to look at different things like production support. What does it mean to actually support our product?
In past discussions, we've talked about software development life cycle, software test life cycle, differences in how to write code, how to debug our code and how to test it. However, we really haven't talked too much about deployment and production support. This is where we're going to focus our discussion today. How do we support our product and our customers?
We're going to look at the different types of problems that can arise, how we can troubleshoot these problems, and different ways that we can fix these problems. Finally, we're going to look at the different ways we can prevent this from happening, in the future.
Technical Support - Fire Fighting Overview:
Production Support Types of Problems Troubleshooting a Problem Ways to Fix the Problem Prevention Root Cause Analysis (RCA) Technical Support - Fire Fighting Issues
Finally, this series comes from our mentoring/mastermind classes. These classes are virtual meetings that focus on how to improve our technical skills and build our businesses.  After all the goals of each member vary.  However, this diversity makes for great discussions and a ton of educational value every time we meet.  We hope you enjoy viewing this series as much as we enjoy creating it. As always, this may not be all new to you, but we hope it helps you be a better developer.
Other Classes, You Might Consider:
Test Project A Review of Version 2.0 Integrating testing into your development flow Become a Better Developer Build A Product Catalog Launching an Internet Business
Transcript Text
[Music] now once we have fixed the problem and we've identified all the particular issues that were out there we need to go back and do what is called a root cause analysis or rca the primary purpose of the rca is to analyze a problem or sequence of events in order to identify what happened why it happened and what can be done to prevent it from happening again so basically this is that after you do the whole software development cycle you go back and you do that review process you go back in and review what went well what didn't go well but here for a root cause analysis we need to look at this from a end user's perspective and a risk so we want to make sure that we've defined the problem correctly that we gathered all the information that came out of not only identifying the particular problem how we can reproduce the problem and what we did to fix the problem so we get all that information we identified the causal factors these are the things that actually triggered what happened so now we have our data in hand we want to look at all the different possibilities that led us to this problem was it an alphanumeric field that really should have been alpha only or numeric only did we have bad data did we have bad security practices were we missing logins were missing role-based security once we have identified the factors we can then determine the root cause or cause is and here we use some of the root cause analysis tools that are on the market we can also go in and just kind of dig through what happened what did we do to actually fix the problem so this could determine the root cause is a combination of what the developer or networking teams or the different groups went in to figure out we take how we figure out we have the bug but then what did we do to fix it now we found the bug how did we fix it and then the last one is okay now that we fixed it now that we have things stable again what can we do to prevent this from happening again what is the recommended and implemented solutions going forward that we can put in place to stop the bleeding make sure this doesn't happen again so there are different things you could do this could also be training this could also be implement additional tools add additional logging and alerts to your system add system monitoring those different agents you can put on your pcs these are just some of the things that you can do at the end for the root cross analysis to make sure that everything is cohesive that you have identified what's going on and what happened and how you can prevent this from happening again people are going to be asking why this happened now as a developer or depend upon where you're at in the company if you are constantly asked why something broke you're going to start getting defensive and with the root cause analysis you have to try to detract yourself from that don't take this personally if you make a mistake own up to it say hey i made a mistake in this process or the code had this particular problem in it here's what happened this is not a blame game this is basically a cause and effect what caused the issue what was the effect and how do we prevent it from happening again when you're doing a root cause analysis try to take the emotions out of it i know it's hard but the rcas are very critical to ensure that you do not have problems in the future and the only way to do that is to really be honest when you do your research here and you actually go through and do the analysis and identify what happened finally before we leave this page the last thing i recommend from an rca is even though you've done the rca even though we've identified all these things the recommended and implemented solutions are identified i also recommend you implement some type of training practice training could be a part of the recommendation but if you have a production support customer support it's still good to do either monthly trainings depending upon your release cycles or at least once a sprint or once a release cycle you definitely get your support teams involved so that they get the training on what's coming what are some of the issues that have been found and identified if you're on the support side of things i definitely recommend that you do at least monthly if not quarterly review of all your rcas to make sure that you don't see a pattern do we see a bad pattern in our software are things breaking what is going on and that can also help you identify root causes in organizational problems strategies release cycle problems development problems so rcas give us a lot of information and from that you want to do add additional things like training lastly i want to leave you with avoid firefighting so when we get into this routine of software support and production support customer support we get through fixing problems we potentially run the risk of getting into a firefighting mode basically every time a customer calls has a potential problem we go out and we quickly fix it so all we're doing is hot fixes we're not going through a normal software process so in a sense firefighting is just it says here so firefighting is just like a real world where the assumption that a fire or where fires are unpredictable and that they may be dealt with immediately or have to be dealt with immediately again hot fixes if this tool is used too frequently we end up in like an emergency action mode all the time and this could lead to poor planning lack or organizational support and is likely to tie up all of our resources that could be used elsewhere now to keep firefighting to a minimum a comprehensive disaster plan might be implemented we could think about if something critical happens how do we address that as a company do we have things like failover if the system goes down are we in a load bouncer if one machine goes down we just take it out of the cycle and put another one in so are things that can be done to help prevent the firefighting model however i've actually been in this situation currently where firefighting unfortunately can be a necessary mode to go into for a while when you're dealing with some critical issues for instance if you're dealing with a legacy application that is so old you have no one left in the organization to support it you have very high technical debt no one knows how things work uh system is unstable you can't even go back and patch the software anymore it's that old or you could be running into unexpected side effects of a code change or an incomplete software deploy that went out to a system incorrectly in these situations you potentially could end up firefighting where you're just constantly you get one issue fixed another one rises you jump to that one another one and it's just repeating pattern that you don't want to get into yes in some situations you're stuck here however you still want to step back at the end of every hot fix or the end of every bug fix and say hey do we have an understanding of what is causing these issues did we do our rca if we did our rca correctly we should start to see a pattern and be able to identify what's causing this critical failure or these firefighting mode and how do we get out of it what is our path to get out of it because we need to make sure we have our resources freed up so that we can continue doing normal business functionality get our software built correctly and keep things moving out the door so just to quickly recap we talked about the overall process of production support we talked about coming in at the customer support level where the customer support rep talks to the customer identifies what the issue is with the customer what type of bugs or problems they're having they get the people involved they troubleshoot the type of problem it is is it customer-facing is it internal back-end is it a configuration issue is it just simply the user forgot their password we go through a troubleshooting process of walking through internally trying to reproduce the bug try identify what's going on again don't panic take that breath don't take it personally keep it all on the level and keep everyone informed we also talked about identifying the different types of risks the risk analysis validation and the particular problems you can run into we also talked about the different types of fixes we could do we talked about the hotfix fixing it real time right now doing normal bug fixing during our software development life cycle testing our code finding bugs fixing them and preventing those bugs from going out in a release we talked about maintenance windows where we take the systems down for scheduled maintenance where we do system patching uh updates system reboots things of that nature and then we talked about patching where instead of doing a hot fix we actually go through a very small release cycle where we fix a combination of bugs get them tested and then roll that out in a timely manner where we actually test it not just quickly reacting to the customer complaint to the fire and then we talked about prevention doing the root cause analysis identifying what caused the problem why it happened and what can we do to prevent training better testing things of that nature and the last thing we talked about was avoid firefighting try not to get into that mode of always being reactive we don't want to be in the mode of always doing hot fixes just reacting to a customer's complaint we want to be mindful and think through the process so that we make sure we're not adding additional bugs into the system and testing our software thoroughly so with that i will open up for questions mike i had a production issue is that the most scary part for a software developer when it comes to production or is it deadline when you're gonna go live like what scares you when you roll the software to production one of the biggest things personally that i deal with with going to production is for the different fields i've been in is health care and ph patient health information or financial information typically yes deadlines are scary but deadlines can come and go they're an arbitrary number in some cases sometimes they're not like when dealing with government health care laws one of the biggest concerns constantly with any type of software development is data integrity making sure that your data is not being exposed that should not be exposed and is being encrypted correctly i've been in a couple situations where we or phi potentially could have been leaked thankfully it wasn't and we caught it in time but that's the biggest concern is when you have a release that goes out and something critically fails you always as a developer fear that you missed something something wasn't done right now typically in larger software organizations you have larger qa departments and there's a lot more testing involved but when you're dealing with smaller startups or typically like just smaller software shops you don't have that larger qa so you don't have the time to necessarily do a full regression of your software so when you make a code change you don't know there is that risk especially if you have to make a hot fix if there is a production issue something sound you fix it you always have that nagging concern or fear did i break something else was there something else that we missed why did it go down and that's why you want to do those things like that root cause analysis i don't know from your perspective rob what you would run into but that that's my perspective yeah the scariest thing actually among those it's probably it probably is production issues because you've got and particularly with healthcare and something where you've got something critical if it's an app that's uh i don't know if it's like it was an angry birds app or something like that or it's just people playing games or something that's for fun that's and even if it's something where people are kind of like if it was like a radio app or something where you're listening to a radio show or tv show or something like that it's not critical necessarily but when you talk about something that is it's either like the lifeblood of the business where if it's not running they're not generating revenue or somebody's literal life blood where it's health and somebody could get sick or could die because of some bug or something like that those obviously are very scary but outside of that i think in general it's actually the ones that probably are the scariest most annoying or whatever and this sort of goes to michael's topic in general are the ones that keep showing up when you have something and it's fixed whether you say you're six or you think it's fixed or somebody else that's on the team has fixed it and then essentially the same bug appears again is it shakes your trust in whether it's fixed the next time around and so it's it is one of those where it gets into the and this gets to so again some of those steps michael mentioned where you really say okay let's step back let's look at this like root cause what really causes let's make sure that this is something that when we fix it this time we can actually fix it sometimes it is very much a case where you look at it and you say oh this is the reason that this bug occurred and so we'll just change this thing and we'll be off and run and we're fine but what you end up doing is you're it's more like you're putting a band-aid on it you're not fixing it if you don't look into it enough sometimes you fix the you're correcting for the result and you're not fixing the actual bug and so it it can and that can be really that can be really nasty because what happens in some cases you end up you build this layer or infrastructure that corrects for this bug on multiple situations then you find out after the fact after you've put in several fixes and made these changes that oh those things really weren't needed there was this other approach i was supposed to take so now you get in the situation where you have your fix you figured it out you fixed it but then you have to go back and find all of those places where you made those adjustments to change for it and basically roll those back because what you were doing is you were doing this this one off kind of fix for these even if you didn't know it and now you've got to go track them back down which also goes to there goes the whole idea of version control and trying to keep good which is very rare good comments about or at least a ticket you know some sort of ticket number which is more common it's done as far as what that change was what it was for so in this case if i had 15 tickets related to this bug in the past now i go back and fix it and i realize i need to go undo those changes i can go back to those 15 tickets and i can look at what was changed i can look at those code commits figure out what was changed and roll it back it's not fun it's not pretty it's going to be probably tedious and time consuming but at least i can be thorough i can actually look at it and say yes these are all the places i changed it and this is where i need to roll them back i did want to mention that i think the thing that i like that you mentioned there early on michael is the don't panic obviously there's the douglas adams thing that just jumps to people's mind but it really is i think that's the that is the cause for stumbling into firefighting and stuff like that more often than not is it there's this we found a bug we want to fix it immediately and it's almost like a panic it's almost like a it's like a rush to get it done as you mentioned we don't step back take a breath and say okay what really happened what do we really need to do to fix it and i think if you can keep a cool head that is a huge first step in dealing with these things properly so that you assess the problem you figure out a solution and you fix it once and you're done as opposed to it keeps recurring and i guess on that one of the things to mention is if you get into a firefighting mode and you're constantly doing hotfix your code is eventually going to become spaghetti code because you're not taking the time to go back and review things correctly and go through the normal software process and you'll run into the risk of is your code reaching unmaintainable or unstable place just from that continuous hotfix mode that's an excellent point and it does make it but just the code itself makes it my unmaintainable at times because you just say you get almost like the spaghetti of all these little patches and little things but also usually because you're doing this quickly it's that whole firefighting mode you're not you're shortcutting some of the processes so your documentation is not up to date your comments aren't up to date you know you may have it but there's a lot of cases where you see this really nice first version of code and there were a bunch of fixes and it just makes the whole thing a mess because you can see where at some point it looked like it was done right and properly thought out and documented all the all the t's were crossed and the eyes were dotted and then you find these like jumbles of code like why is this here or you'll find magic numbers and all kinds of other just bad things showing up in the code that yeah you started off great and then because you didn't follow through and keep your head you essentially ruined a good thing excellent point i would like to thank everyone for your time today we appreciate your time and if you'd like to discuss any of our topics further you can reach out to us at info developer new dot com you can reach us on our website development.com contact us we're also on twitter at developernerd we're on facebook which we get that occasionally we're at facebook.com developmenter we're also on vimeo you can find our videos on vimeo and we now have a new youtube channel you can google developer on youtube and find our videos there our goal is making every developer better have a wonderful day [Music] you
Transcript Segments
[Music]
now once we have fixed the problem and
we've identified all the particular
issues that were out there we need to go
back and do what is called a root cause
analysis or rca
the primary purpose of the rca is to
analyze a problem or sequence of events
in order to identify what happened why
it happened and what can be done to
prevent it from happening again
so basically this is that after you do
the whole software development cycle you
go back and you do that review process
you go back in and review what went well
what didn't go well but here for a root
cause analysis we need to look at this
from a end user's perspective
and a risk
so we want to make sure that we've
defined the problem correctly that we
gathered all the information that came
out of not only identifying the
particular problem how we can reproduce
the problem and what we did to fix the
problem so we get all that information
we identified the causal factors
these are the things that actually
triggered what happened
so now we have our data in hand
we want to look at all the different
possibilities that led us to this
problem was it an alphanumeric field
that really should have been alpha only
or numeric only did we have bad data
did we have bad security practices
were we missing logins were missing
role-based security
once we have identified the factors we
can then determine the root cause or
cause is
and here we use some of the root cause
analysis tools that are on the market
we can also go in and just kind of dig
through what happened what did we do to
actually fix the problem
so this could determine the root cause
is a combination of what the developer
or networking teams or the different
groups went in to figure out we take how
we figure out we have the bug but then
what did we do to fix it
now we found the bug
how did we fix it and then the last one
is okay now that we fixed it now that we
have things stable again what can we do
to prevent this from happening again
what is the recommended and implemented
solutions going forward that we can put
in place to stop the bleeding
make sure this doesn't happen again
so there are different things you could
do this could also be training
this could also be implement additional
tools add additional logging and alerts
to your system add system monitoring
those different agents you can put on
your pcs
these are just some of the things that
you can do at the end for the root cross
analysis to make sure that everything is
cohesive that you have identified what's
going on and what happened and how you
can prevent this from happening again
people are going to be asking why this
happened
now as a developer or depend upon where
you're at in the company
if you are constantly asked why
something broke you're going to start
getting defensive and with the root
cause analysis you have to try to
detract yourself from that don't take
this personally if you make a mistake
own up to it say hey i made a mistake in
this process or the code had this
particular problem in it here's what
happened
this is not a blame game
this is basically a cause and effect
what caused the issue
what was the effect and how do we
prevent it from happening again
when you're doing a root cause analysis
try to take the emotions out of it i
know it's hard but the rcas are very
critical to ensure that you do not have
problems in the future and the only way
to do that is to really be honest when
you do your research here and you
actually go through and do the analysis
and identify what happened
finally before we leave this page the
last thing i recommend from an rca is
even though you've done the rca even
though we've identified all these things
the recommended and implemented
solutions are identified
i also recommend you implement some type
of training practice
training could be a part of the
recommendation but if you have a
production support customer support it's
still good to do either monthly
trainings depending upon your release
cycles or at least once a sprint or once
a release cycle you definitely get your
support teams involved so that they get
the training on what's coming
what are some of the issues that have
been found and identified if you're on
the support side of things i definitely
recommend that you do at least
monthly if not quarterly review of all
your rcas to make sure that you don't
see a pattern do we see a bad pattern in
our software are things breaking what is
going on
and that can also help you identify root
causes in organizational problems
strategies release cycle problems
development problems so rcas give us a
lot of information and from that you
want to do add additional things like
training
lastly i want to leave you with avoid
firefighting
so when we get into this routine of
software support and production support
customer support we get through fixing
problems
we potentially run the risk of getting
into a firefighting mode basically every
time a customer calls has a potential
problem we go out and we quickly fix it
so all we're doing is hot fixes
we're not going through a normal
software process
so in a sense firefighting is just it
says here so firefighting is just like a
real world where the assumption that a
fire or where fires are unpredictable
and that they may be dealt with
immediately or have to be dealt with
immediately
again hot fixes
if this tool is used too frequently we
end up in like an emergency action mode
all the time and this could lead to poor
planning lack or organizational support
and is likely to tie up all of our
resources that could be used elsewhere
now to keep firefighting to a minimum a
comprehensive disaster plan might be
implemented
we could think about if something
critical happens how do we address that
as a company do we have things like
failover if the system goes down are we
in a load bouncer
if one machine goes down we just take it
out of the cycle and put another one in
so are things that can be done to help
prevent the firefighting model
however i've actually been in this
situation currently where firefighting
unfortunately can be a necessary mode to
go into for a while when you're dealing
with some critical issues
for instance if you're dealing with a
legacy application that is so old you
have no one left in the organization to
support it
you have very high technical debt
no one knows how things work
uh system is unstable you can't even go
back and patch the software anymore
it's that old or you could be running
into unexpected side effects of a code
change or an incomplete software deploy
that went out to a system incorrectly
in these situations you potentially
could end up firefighting
where you're just constantly you get one
issue fixed another one rises you jump
to that one another one and it's just
repeating pattern that you don't want to
get into
yes in some situations you're stuck here
however you still want to step back at
the end of every hot fix or the end of
every bug fix
and say hey do we have an understanding
of what is causing these issues
did we do our rca if we did our rca
correctly we should start to see a
pattern and be able to identify what's
causing this critical failure or these
firefighting mode
and how do we get out of it what is our
path to get out of it because we need to
make sure we have our resources freed up
so that we can continue doing normal
business functionality get our software
built correctly and keep things moving
out the door
so just to quickly recap we talked about
the overall process of production
support we talked about coming in at the
customer support level where the
customer support rep talks to the
customer identifies what the issue is
with the customer what type of bugs or
problems they're having
they get the people involved
they troubleshoot the type of problem it
is
is it customer-facing
is it internal back-end
is it a configuration issue
is it just simply the user forgot their
password we go through a troubleshooting
process of walking through
internally trying to reproduce the bug
try identify what's going on
again don't panic
take that breath don't take it
personally keep it all on the level and
keep everyone informed
we also talked about identifying the
different types of risks the risk
analysis validation and the particular
problems you can run into
we also talked about the different types
of fixes we could do
we talked about the hotfix fixing it
real time right now
doing normal bug fixing during our
software development life cycle testing
our code finding bugs fixing them and
preventing those bugs from going out in
a release
we talked about maintenance windows
where we take the systems down for
scheduled maintenance where we do system
patching uh updates system reboots
things of that nature and then we talked
about patching where instead of doing a
hot fix we actually go through a very
small release cycle where we fix a
combination of bugs get them tested and
then roll that out in a timely manner
where we actually test it not just
quickly reacting to the customer
complaint to the fire
and then we talked about prevention
doing the root cause analysis
identifying what caused the problem why
it happened and what can we do to
prevent training
better testing things of that nature and
the last thing we talked about was avoid
firefighting try not to get into that
mode of always being reactive
we don't want to be in the mode of
always doing hot fixes just reacting to
a customer's complaint we want to be
mindful and think through the process so
that we make sure we're not adding
additional bugs into the system and
testing our software thoroughly so with
that i will open up for questions
mike i had a production issue is that
the most scary part for a software
developer when it comes to production or
is it deadline when you're gonna go live
like what scares you when you roll the
software to production
one of the biggest things personally
that i deal with with going to
production is for the different fields
i've been in is health care and ph
patient health information or financial
information
typically
yes deadlines are scary but deadlines
can come and go they're an arbitrary
number
in some cases sometimes they're not like
when dealing with government health care
laws
one of the biggest concerns constantly
with any type of software development is
data integrity making sure that your
data is not being exposed that should
not be exposed and is being encrypted
correctly i've been in a couple
situations where we
or phi potentially could have been
leaked thankfully it wasn't and we
caught it in time but that's the biggest
concern is when you have a release that
goes out and something critically fails
you always as a developer
fear that you missed something something
wasn't done right now typically in
larger software organizations you have
larger qa departments and there's a lot
more testing involved but when you're
dealing with smaller startups or
typically like just smaller software
shops you don't have that larger qa so
you don't have the time to necessarily
do a full regression of your software so
when you make a code change you don't
know
there is that risk
especially if you have to make a hot fix
if there is a production issue something
sound you fix it you always have that
nagging concern or fear
did i break something else
was there something else that we missed
why did it go down and that's why you
want to do those things like that root
cause analysis
i don't know from your perspective rob
what you would run into but that that's
my perspective
yeah the scariest thing actually
among those it's probably it probably is
production issues
because you've got and particularly with
healthcare and something where you've
got something critical if it's an app
that's uh i don't know if it's like it
was an angry birds app or something like
that or it's just people playing games
or something that's for fun
that's and even if it's something where
people are kind of like if it was like a
radio app or something where you're
listening to a radio show or tv show or
something like that it's not critical
necessarily but when you talk about
something that is it's either like the
lifeblood of the business where if it's
not running they're not generating
revenue or somebody's literal life blood
where it's health and somebody could get
sick or could die because of some bug or
something like that
those obviously are very scary but
outside of that i think in general it's
actually the ones that probably are the
scariest most annoying or whatever
and this sort of goes to michael's topic
in general are the ones that keep
showing up when you have something and
it's fixed whether you say you're six or
you think it's fixed or somebody else
that's on the team has fixed it
and then essentially the same bug
appears again is it shakes your trust in
whether it's fixed the next time around
and so it's it is one of those where it
gets into the and this gets to so again
some of those steps michael mentioned
where you really say okay let's step
back
let's look at this like root cause what
really causes
let's make sure that this is something
that
when we fix it this time we can actually
fix it sometimes it is very much a case
where you look at it and you say oh this
is the reason that this bug occurred
and so we'll just change this thing and
we'll be off and run and we're fine
but what you end up doing is you're it's
more like you're putting a band-aid on
it you're not fixing it if you don't
look into it enough sometimes you fix
the
you're correcting for the result and
you're not fixing the actual bug
and so
it it can and that can be really that
can be really nasty because what happens
in some cases you end up
you build this
layer or infrastructure that corrects
for this bug on multiple situations
then you find out after the fact after
you've put in several fixes and made
these changes that oh
those things really weren't needed there
was this other approach i was supposed
to take
so now you get in the situation where
you have your fix you figured it out you
fixed it but then you have to go back
and find all of those places where you
made those adjustments to change for it
and basically roll those back
because what you were doing is you were
doing this this one off kind of fix for
these even if you didn't know it and now
you've got to go track them back down
which also goes to
there goes the whole idea of version
control and trying to keep good
which is very rare good comments about
or at least a ticket you know some sort
of ticket number which is more common
it's done as far as what that change was
what it was for
so in this case if i had 15 tickets
related to this bug in the past
now i go back and fix it and i realize i
need to go undo those changes
i can go back to those 15 tickets and i
can look at what was changed i can look
at those code commits figure out what
was changed and roll it back
it's not fun it's not pretty it's going
to be probably tedious and time
consuming but at least i can be thorough
i can actually look at it and say yes
these are all the places i changed it
and this is where i need to roll them
back
i did want to mention that i think the
thing that i like that you mentioned
there early on michael is the don't
panic obviously there's the douglas
adams thing that just jumps to people's
mind but it really is
i think that's the that is the cause for
stumbling into firefighting and stuff
like that more often than not is it
there's this
we found a bug
we want to fix it immediately
and it's almost like a panic it's almost
like a it's like a rush to get it done
as you mentioned we don't step back take
a breath and say okay what really
happened
what do we really need to do to fix it
and i think if you can keep a cool head
that is a huge first step in dealing
with these things properly so that you
assess the problem you figure out a
solution and you fix it once and you're
done as opposed to it keeps recurring
and i guess on that one of the things to
mention is if you get into a
firefighting mode and you're constantly
doing hotfix your code is eventually
going to become spaghetti code because
you're not taking the time to go back
and review things correctly and go
through the normal software process
and you'll run into the risk of is your
code reaching unmaintainable or unstable
place just from that continuous hotfix
mode that's an excellent point and it
does make it but just the code itself
makes it my unmaintainable at times
because you just say you get almost like
the spaghetti of all these little
patches and little things but also
usually because you're doing this
quickly it's that whole firefighting
mode
you're not you're shortcutting some of
the processes so your documentation is
not up to date your comments aren't up
to date you know you may have it but
there's a lot of cases where you see
this really nice first version of code
and there were a bunch of fixes and it
just makes the whole thing a mess
because you can see where at some point
it looked like it was done right and
properly thought out and documented all
the all the t's were crossed and the
eyes were dotted
and then you find these like jumbles of
code like why is this here or you'll
find magic numbers and all kinds of
other just bad things showing up in the
code that yeah you started off great
and then
because you didn't follow through and
keep your head you essentially ruined a
good thing
excellent point
i would like to thank everyone for your
time today
we appreciate your time
and if you'd like to discuss any of our
topics further you can reach out to us
at info developer new dot com you can
reach us on our website development.com
contact us we're also on twitter at
developernerd we're on facebook which we
get that occasionally we're at
facebook.com developmenter
we're also on vimeo you can find our
videos on vimeo and we now have a new
youtube channel
you can google developer on youtube and
find our videos there our goal is making
every developer better have a wonderful
day
[Music]
you