The Zeek Blog

We Don’t Write Often, But When We Do... We Do It Here.

How To Speak Geek, Part 4 – Bug Reporting

25 May

This is the final installment of my four part series on how to communicate with your developer. Part 1 covered Interviewing Your Potential Developer, part 2 covered Planning & Project Management, and part 3 covered Version Control.

Bug Reporting

Problems are going to occur. The way your developer handles problems is what sets good developers apart from bad ones. I have never found a website that was 100% bug free; not even the largest websites. Knowing this ahead of time may help you handle problems more rationally.

Do your best to keep emotion and drama out of the situation. When a problem arises, take a deep breath and count to 10. Most emergencies are usually resolved very quickly. What may seem like a major problem to you might actually be a minor technical problem that your developer can fix in 5 minutes.

Your bug reporting procedure should be established during the planning phase of your project. You and your developer should agree on how emergencies are handled as well as non-emergencies. You need to agree first on what constitutes an emergency. Typically on our projects, an emergency is when any part of the site is not accessible by the public. This happens when either a page fails to load or the server is acting slow for some reason. For all other situations, we have our clients submit a ticket to our project management system.

Developers do not like guesswork. When reporting a bug, don’t send an email to your developer with something like “My site isn’t working.” Lack of detail is very frustrating for you developer and the “hunting” time can cost you extra money.

Good bug reporting is an art form that can take some practice to master. To report a bug, you need to give as much detail as possible in a concise document.  Start by giving a brief description of the issue in plain English. Don’t try to analyze any technical issues.

Then, give the exact steps to reproduce the problem. Tell your developer exactly what you were doing at the time the problem occurred. Also, include your operating system, browser version and any virus or firewall software you might be running.

An easy way to send your system details to your developer is Our customer service people at Real Estate Shows use this site extensively. When a customer reports a problem, they have the customer send an email from that site.

VERY IMPORTANT! When reporting problems, make sure you specify the priority. Be realistic. Is this a mission critical problem? Can it wait a few days? A week? If you don’t regularly specify a priority, your developer should get into the habit of asking the priority.

If your site is inaccessible, check out before contacting your developer. This site will let you know if the problem is limited to just you or if the public is experiencing it as well.

A Few Additional Tips

Brainstorming is a good thing, but there is a fine line between brainstorming and feature creep. As you see your project being built, your mental wheels will start to spin. You will be thinking of additional enhancements to these features. However, if you want them added in your current working phase, be prepared to revise your statement of work. There will be an impact on the schedule and/or budget.

Many developers speak in languages that sometimes I don’t even understand. You will hear them refer to technology using terms and acronyms that will make your head spin. And they will rattle them off like you are supposed to know exactly what they are referring to. When this happens, make Wikipedia and Google your friend. Jot down the terminology and look it up later.


The bottom line is that many of the horror stories that I hear could have been avoided with clear communication. While there are a few bad seeds, I believe that most developers are not maliciously screwing up projects. Several factors may have contributed to projects that went wrong. If you have a developer horror story, I encourage you to look back at what could have been done differently to avoid the problem(s). Learn from it so that you don’t fall into the same trap next time around.

Tags: , , ,

Archived Comments

  1. ines June 9, 2010 at 7:37 pm #

    If only I would have read this 3 years ago. I hired what I thought was a reputable and responsible developer and ended up with a huge mess. The question here is, once you have an established site and know you have to find a new developer to help you with glitches and bugs – how do you find someone that will take on the project of a poorly designed site to begin with?
    Steve ….you’re da man! really!
    thanks for that link…priceless

  2. Jeff Turner June 11, 2010 at 1:31 pm #

    I think the suggestions Steve makes here will help you even if you’ve chosen a bad developer who says and does all the right things up front. You’ll know more quickly whether they are are not getting the job done correctly. The sooner you can come to that conclusion the better, as you now well know.