Yes, I’m afraid it’s true, there is no such thing as a perfect computer program. This is because of a number of reasons:

1. No one is perfect (seriously, not even me).
2. This stuff is actually harder than it looks.
3. In large, complex systems, there are often too many interdependencies for anyone, or even any one team, to keep track of. Change one thing, risk breaking another.
4. Systems can be built on old, bad, or broken code – if you’re cutting costs by leveraging an existing system, you may have to deal with a legacy system that gets you 80% of the way there for 10% of the cost, but you might have to pay another 10% in quality assurance (QA).
5. Code is logical and creative. It requires both science and art to get that cool zip code search thing you wanted to work just right… and there may be 100 ways to do it. We’ve got to try and think of the best, easiest, simplest, most cost effective way that still does the job and doesn’t kill the hardware.

So there is a lot working against you when it comes to designing your iPhone game or document management system or whatever it is you’re having built. Now if you’re in Tampa like us, you could come down to our offices and point to things on the screen and look us in the eyes and hit us with sticks until we got it, and there would still be the occasional bug.

1. First off, imagine developers are the most incredible stupid people you have ever met. That might not even be too difficult!
2. Be excessively descriptive. “That thing in the top corner should flash,” does not tell an engineer anything. Even if you don’t know what that “thing” is called you could try something more like: “In the top left had corner, there is a small arrow with my score in a blue box. Can we make it so that the box around the score flashes between green and yellow every .5 of a second?”
3. Develop a test cycle with your programmer. Have a system where they fix something, and then you or your QA team respond to the change in a standard way – either marking it off the list, explaining what still needs to be fixed, or sending it off for someone else’s approval… as long as you are both on the same page and timeline.
4. Use a bug tracking system like Trac or Redmine. We’re a big fan of Redmine because it does a lot of other tasks for us, but anything is better than nothing.
5. Work out a common language. Does “DONE” mean we’ve finished this and are moving on? Or does it mean, “We’ve handled the problem, we think. Can you please check it and see if it does what you wanted?”
6. If you’re not going to use a tracking system, a common editable document like Microsoft Word is sometimes easier – especially for small projects where you don’t have time to learn a whole new system. Decide on a color of text for each stage of development. So things “In Progress” are blue, and things “Done and Awaiting Testing” are in green, etc.
7. If you’re going to use email as a bug-tracking tool, keep the subject the same for each bug, so a threaded email program can keep track of each change.
8. Take lots of screen shots – a picture speaks a thousand words. Use them! Big red arrows with labels are not seen as condescending in a world where communication is difficult.
9. Use screen casts. There are a ton of great products out there (I’m a big fan of Camtasia), and even free services like screencast.com (they’ll give you 2GB of free space). If a picture speaks a thousand words, then a video is 1000 words by 30 frames a second.

Being direct, descriptive and sharing a common reference point are pretty obvious communication techniques for any situation, but we don’t always keep them in mind when we’re frustrated that something is not working quite the way we intended. What’s even worse however is when you can see that something was done the wrong way and your instructions could have been interpreted to mean zig when you wanted zag. If we all stuck to a few of these rules (and that goes for developers doubly – this is your job, after all) the QA process would feel a lot less painful.