How we debug difficult website problems

We’re a strange bunch of web developers because not only are we good at debugging and solving complicated problems, but we actually enjoy them. Taking a project that is a mess, where it isn’t obvious where to even start, and in the end giving the client a packaged system that works as intended, is strangely satisfying. In this article I’ll outline some of the methods we use to get to the bottom of things.

Never assume anything

If client tells us that something is the cause of the problem, then certainly we need to consider this, but we don’t rely on it. This is especially true when multiple people have unsuccessfully worked on the project, because they have quite often been looking in the wrong place, hence why it isn’t fixed. Similarly, if a client tells you something is working, make sure you satisfy yourself that this is true. Just imagine the number of times that we have been told that a password is correct, only to find out that this was the issue all along!

Multiple causes

Many problems are not a simple single error that magically appeared overnight, but a series of minor issues that all compound and cause a problem. The important thing to remember here is that, when eliminating potential causes, you need to be careful not to eliminate something that works, but only in the specific case for which you tested. For example, Bob could test something in Google Chrome when not logged in, and determine that Google Chrome is not the issue because everything works. In reality there could be an issue that only manifests for logged in users using Google Chrome.

Reproduce the problem

Have you ever had a strange noise coming from your car, taken it to the garage, and the noise stopped? Well, that makes it very hard for the mechanic to diagnose. It’s the same with websites. Flipping this on its head, if you can’t reproduce the problem then this is a blessing in disguise. Why? Because you can keep changing your environment, step by step, to match the clients until suddenly the problem appears, giving you your first lead!

Take a step back

Often trying to find a problem in isolation is difficult, and sometimes it’s impossible as the cause is a wider issue. So, take a step back, look at the system as a whole, and see if that provides any clues. Often this initiates a lightbulb moment and an “ah, I never knew that this system linked to that, this changes things” thought pops in to your head.

Assess the timeline

“It just stopped working for no reason” is unlikely. Something has probably changed. Whether this is something the user did and is trying to hide, something the user did that they didn’t know caused an issue, a system update, or a 3rd party influence. Of course, things can stop by themselves from time to time, usually when a certain limit has been reached, or even a date (think Y2K bug), or sometimes the issue has been there forever, just no one noticed.

No shortcuts

This is likely the most important point, do it properly, methodically, carefully and don’t take shortcuts. If you miss something, you may have to go over and redo a lot of what you’ve done. My dad, a very wise man, used to say “Aaron, do it properly, do it once”.

Common issues

That being said, sometimes it is worth a quick Google, or asking ChatGPT. Okay, experience will help here as you’ll know what to search for, but it could be a common issue that everyone is experiencing. Just don’t get caught in the trap of looking for ‘quick wins’ for days!

Divide and conquer

This doesn’t work in all circumstances but, when possible, it’s an invaluable tool. If you can eliminate a large part of the system in one go you’ve made your issue much smaller. Sub-techniques here involve commenting out or turning off large areas of code or functionality with the premise that if it isn’t there it can’t be the issue. Just go careful not to make any incorrect assumptions.

Talk to ducky

Eh, what? Sometimes explaining your process to a colleague helps as, by saying it out loud and step-by-step, you make yourself think more logically. It’s better if your colleague plays devil’s advocate, asks awkward questions, and makes you double check things, but even if they don’t, the act of explaining the situation in itself can still help. In fact, even if they are not technically minded, or even a rubber duck, this method still works.

Be methodical

People who are often good at debugging issues are methodical and logical thinkers; they make good developers. Don’t attack issues with an unordered scatter-gun approach, that will lead to nowhere and is how many agencies waste resources. You need a carefully thought-out plan, and to take your time. Rushing will end up taking longer.

Intermittent issues

Well, they are a pain in the ass. But remember that they appear intermittent to you, but there is a logical reason why they appear when they do.

Create an alternative

Sometimes users get stick in their ways of performing a task in a certain way, and quite often the bug in question is due to their processes that are in place for legacy reasons. Rather than fix the bug, it can sometimes be quicker to bypass by changing or replacing the whole process with a different, better, or newer technology.

Test, test and test again

A common mistake made is where people fix what they think is the issue, only to find it rears its ugly head again in the future. Once you have found the solution, make sure you understand why it works, and try as many edge-cases as possible to break it. Test it, test the system, around it, get the client to test it, and test it again. Remember that the point of testing is not to prove that what you have done works, but to find an example when it doesn’t.

Get a pro to help

Of course, if you don’t know where to start, have wasted too much time on it, or if other web agencies have failed, maybe it’s time to get in touch with us! This is what pushes our buttons, let us help you fix it once and for all. We are Webbed Feet; we enjoy fixing web development projects.