IT Week this week references the Web Effectiveness Report 2003, which, amongst other things, reveals that only 19% of web site managers surveyed review their log files to look for problems with their site.

When we originally built BlackStar we were fairly novice Perl programmers. We knew that all Perl should really have “strict” mode and “warnings” turned on — so we made sure we did that. But as long as everything ran correctly, we didn’t really pay much attention to the warnings that were emitted.

But after a while we realised that all that clutter in our logs was highly distracting, and ensured that nobody really paid them much attention — thus obscuring all the useful information about real problems.

So we decided to clean this up, to make sure that anything appearing in the log would most likely be a symptom of an actual problem, of which someone should probably be notified straightaway.

This was much easier to decide than to actually implement, however. We were introducing all manner of new quality procedures at the time, so it was relatively easy to at least decree that any new code, or any alteration of existing code, should be free from warnings. This way we could at least halt the growth of new warnings (although with site visits growing 30-40% per month, the volume of messages was still growing quickly). We even added into the programming schedule a little time devoted to removing some of the most egregious offenders, which probably removed about 50% of the output.

The slow clean-up of having the old code gradually tidied in passing wasn’t going to get us anywhere fast enough though. So we introduced a new system that was disarmingly simple, but remarkably effective. Every night a process collated the error logs from across the various web servers, and generated a report of the ten most common problems. This report would be emailed to the entire programming team, and the next day one person would take responsibility for ensuring that the top item on that list vanished.

This approach proved very effective and within a few months the volume of warnings had decreased dramatically. It was so successful that we started to apply the approach to many other areas of the business. Any problem that was monitored over time was a candidate for it – and with an entirely web based business we had a lot of data to monitor. Someone became responsible for checking the list of the most common search terms that returned no results, and adding a re-mapping so that that search would automatically be transformed into what the person probably wanted. Someone else would ensure that the most visited DVD page that didn’t link to the VHS of the same item was given that cross-reference. Someone in the warehouse would upload the cover of the most viewed item in stock that hadn’t previously been scanned.

Most of these tasks took less than 5 minutes. They would rarely be a top priority in amongst the constant fire fighting, growth-pains, and breakneck pace of developing new features and systems in the crazy world of exponential growth. In normal circumstances none of these things would even have appeared in someone’s list of top 10 priorities. But the simple action of ensuring that each day the top occurrence of each problem was removed created a staggering cumulative effect.

The art of time management is usually a matter of ranking your items by importance and urgency, and prioritising according to how high things appear on each axis. But most books, articles and seminars on the topic stop there. Spending a few minutes each day doing something that is neither particularly important, nor particularly urgent, but that has a beneficial outcome, has value. When everyone in an organisation is doing likewise, and those tasks are automatically selected based on their potential benefit, that value can be enormous.