Someone recently asked me what I thought were the toughest bugs to find and fix.

I’m pretty sure they wanted a technical answer — one that would dive deep into the code and talk about the stickiest math problem, logic issue, endless loop, null pointer error, or buffer overflow.

This was one technology guy to another technology guy, so you would assume it would be something like the stuff above.

Instead, I told him that the toughest bugs are the oldest bugs. That’s right — it doesn’t matter how hard or how deep in the code the bug is, the faster you find it, the easier it is to deal with.

This is because after a developer has released their code, they treat it like a known and trusted quantity. As such, they stop thinking about it. They expect it to work just like they expect the sun to rise in the east. If the sun is up, then that code works. They don’t think about it any longer and they may actually forget that they wrote it.

So, the best way to debug your code is to find the bugs as soon as possible. … Before you write more code and forget what you were working on. Before you commit more code and you’re unsure what is causing the bug. Before you release it to the public.

With our software teams, we start that process with unit tests. Those are followed by peer reviews. This leads to an automated system that verifies the project builds without errors. It also runs the unit tests and checks the code style. This is followed by verification that the feature works as expected — including math checks. Then there’s manual testing and finally automated tests using Selenium. After all this, the whole application is tested. 

That gives us many chances to find a bug before it is released.

The majority of that testing is done on the feature itself, which reduces the amount of code that must be reviewed and debugged. The smaller the footprint, the less investigative work you need to do. The sooner you start, the more familiar you are with the affected code.

One of the tenants of the Agile Scrum development methodology is to inspect and adapt. Review your work and change it if it needs to be changed. This is often applied to project stakeholders who are supposed to get frequent demos so that they can react early and request changes before you complete the project. 

But I believe this also applies to the software development process. As software engineers, if we pause a little to inspect our code and adapt it, then we will fix our bugs more quickly. In the end, the minutes we spend finding and fixing errors now will save us hours and days later.

This isn’t about never writing a bug. It’s about finding our errors first and fixing them. Someone else once told me, “it’s not about whether you fail, it’s how you respond when you do fail that sets you apart.” Expecting bugs, looking for them and fixing them right away is the fastest and most responsible way to deal with them.