Debugging Cycle

[00:00:00]
>> So I wanna start with some thoughts on how to fix bugs. And this is just a very generic cycle that you could make up about really just about anything, but I'm gonna use it to kinda organize my thoughts here. So fixing bugs is about identifying that a bug exists, because many times we don't even know that a bug is happening until far too late.

[00:00:20]
Isolating where the bug is in the overall system, resolving it, and then finally preventing it from happening in the future. And so I have some thoughts on each one of these. You can identify bugs at lots of different phases of the development cycle. During development, like when we're actually writing it, we'll catch bugs all the time.

[00:00:42]
I catch bugs all the time just as I'm writing something and I refresh the page and, that doesn't look right. I must have screwed something up. I just caught a bug. If I don't catch it and I pass it on, maybe my buddy goes through and tests it, or maybe I'm lucky enough to have a feel full QA department where I'm working.

[00:00:58]
Maybe they'll catch a bug where I'm testing it. If it goes all the way out into a real environment, hopefully I'll have some sort of monitoring technology to tell me when a bug is happening. And if none of those things happen, maybe your users will tell you, hey, your checkout form is screwed up.

[00:01:16]
I can't buy this thing and I really, really need to have my widgets for tomorrow. And what's interesting about these things is that the earlier you catch that bug, the cheaper, better, and faster everything is. Now I can't say that how cheaper, how better, how faster. That's all dependent on your context.

[00:01:37]
But what I can say is that it's definitely cheaper for the developer themselves to find the bug and fix it in their minds than it is to wait all the way until the user reports it. Especially because if you wait all the way for the users to report it, a fraction of them won't even bother.

[00:01:54]
They'll just move on and try something else and they'll go to Facebook and buy from the other store or whatever. So if you fall all the way out there, that's the worst possible case because you're losing revenue. You're losing customers. You're losing users. You're losing whatever it is you're trying to do with your web application.

[00:02:14]
Once we know that there's a bug, the developer, we need to take over and start trying to understand where does this bug exist? And there can be lots of different things we need to narrow down. There's context that we need to understand about where the bug happened. What browsers is it happening in?

[00:02:33]
Is it only happening in Chrome, Chrome and Safari? Is it happening everywhere? Is it only IE9? Where does it happen? Because that can help point at where the root cause is, on whether or not it's an issue with some interaction, some compatibility of an API you're using. What pages is it happening on?

[00:02:52]
Often you'll have different pieces of JavaScript running on different URLs. Is it happening to one user, a certain class of users, all users? And what scripts are generating these errors? If you have that, you also need to understand this timeline of events. A web application is this incredibly complex state machine.

[00:03:16]
Even if you're building an application that probably is maintaining some state. And then the DOM itself is another set of state. And the browser is another set of state. And then every remote API you're talking to has another set of state, with what cookies, and tokens, and remote sessions are being kept.

[00:03:35]
And so you have all of these different state machines operating. What series of events got you into the situation where a bug existed? How do we go back through and understand those events so that we can isolate where the bug is coming from? So isolating the bug is about understanding your context, understanding the timeline of how did you get into this situation, and using those two things to dig into the root cause of why bug a happened.

[00:04:10]
Once you actually know that, we can begin to actually resolve the bug. Now, this is very contextual dependent of what bug are you solving. A very interesting conversation tends to happen at this phase, especially if it's 11:30 on a Friday night and you have to get this bug out right away.

[00:04:29]
What do you fix? Do you just make the small hacky duct tape change that you need to do to get the thing fixed and move on with your day? Or do you fix it the, quote unquote, right way and change the 17 files that need to go into, be whatever the architects claimed was the right way to solve the problem?

[00:04:49]
And so you need to have a conversation maybe just with yourself or maybe with your team about the risk, change, and impact of your app. What are those factors for you? An application has a different impact on the world based on what you're doing. You wouldn't make the same decisions if you were writing software for a pacemaker as if you're writing software for an e-commerce API, as if you're writing software for a live video broadcast, or a JavaScript error monitoring tool.

[00:05:21]
We all have a different idea of what is the impact to different levels of bugs with our app. And what is the risk of making changes at different point in time? How risky is it to deploy for you? Some systems have a huge amount of maturity built up that they can deploy all the time and have very, very low risk.

[00:05:40]
Because they have all the testing and monitoring and analytics tools to know when something goes wrong. But if you don't have that, if deployment is a scary, risky thing for you, you can't change as much and expect good results. We'll talk about that more. And finally, prevention. Once you've actually fixed it, fixed a bug, how do you prevent it from happening again?

[00:06:06]
Now there's a couple of different tools we can think about on how to do that. First is regression tests. How many people have heard of regression tests? So a regression test is not like a different kind of test. It's not like a different scope of testing like unit testing, integration testing, end-to-end testing, regression testing.

[00:06:27]
A regression test is just a test in any of those scopes that you use to prevent a bug from re-occurring. So if you have a bug that you just hit yourself in the head on like, I can't believe I let that happen. That might be a good candidate to write a regression test somewhere in your code so that you make sure you don't make that same mistake again.

[00:06:48]
You can also prevent bugs from happening by changing your processes. And by processes, I mean both the manual, corporate processes that a lot of us have to adhere to, but also just automation. Automated scripts, deployments, continuous integration, those sort of things. Can we make changes to those sort of things that will prevent a bug from happening?

[00:07:09]
And thinking about that after we've pulled a bug or fixed a bug is important to prevent it from happening again. Or some places go too deep on this. And so sometimes the right solution is to do nothing. Both adding tests to your code and adding process have a cost.

[00:07:31]
They'll cost you in maintenance. They'll cost you in slowing down development. They'll cost you in a lot of different ways. So think about the bug that you just solved and know whether or not is it worth raising your cost structure to prevent it from happening again? Or was it just a silly little trivial thing that you'll never make that mistake again.

[00:07:56]
So some things to think about to prevent bugs, regression tests, changing some processes, or doing nothing. That's really all I had to say about how to fix bugs. We're gonna go in and do a lot more examples now.