Checklists are often skipped over as an aid to problem solving. They shouldn't be. They provide a quick step plan to narrowing down a search or criteria to identify a problem.

This week was one of those week's where I was caught out with a problem. In debugging an application, I couldn't work out why the plugin I installed and setup wasn't being called in a screen. Despite changing what I thought was the correct screen, nothing was happening. It turns out I was in fact updating the wrong screen. A simple mistake to make in most applications but here the application is slightly different.

This application I am referring to is in fact a content management system. It contains a number of different layouts depending on the type of site that you want. This means that there are hundreds of files that make up the user-interface to the application. There is a default file representing each particular screen and then there is a screen for each different type of site that can override the default screen if we need it. This means that there are hundreds of files representing the different screens in this application. Some are similar and as a result, ensuring you are updating the correct screen is important.

So where does the checklist fit in then? Well as I was debugging the application on a particular type of site, following through a number of steps would have ensured that I was in fact debugging the correct screen. Thinking of each item on the checklist as a way of narrowing down the problem allows you to eliminate easy to find problems, eventually narrowing down you scope to the actual problem you were having.

I've since started putting together a number of checklists for identifying such problems. I've done a number of debugging sessions like this where I missed a step in identifying the actual issue and instead spent a few hours going down the wrong path. It's time that I don't want to waste in the future. I'd rather identify the problem quickly, fix it and crack on with something else.