This article is an attempt to boil the author's tool development experience down into some reusable snippets of wisdom - a kind of first pass "best practices" document. Some of it falls under the realm of common sense, some of it might even conflict with your own experiences, but hopefully you'll find something useful!

Never Let an Error Occur More than Once

Every time someone comes to you with a problem, you have to:

1. Interpret their observations ("It just stopped working", "I didn't do anything", "It just broke")
2. Extract an accurate set of symptoms
3. Form a diagnosis
4. Figure out if it's a new problem or just another manifestation of a known issue.
5. Come up with a fix

That's a lot of work. You don't want to be doing any more of that than you have to. So when errors crop up, you want to fix them before they occur again and force you to repeat the whole tiresome process.

In short, you should aspire to laziness. But like all good things, the attainment of true laziness requires some work.

There is also a bit of a conflict here. When users encounter problems, they just want quick workarounds to let them get on with their work. But tracking down an issue and fixing it properly once and for all might take you a while.

A good compromise is to provide the user with an immediate kludge (if there is one), but make them give you a postmortem snapshot of the data involved so that you can replicate, examine and fix the problem at leisure. The last thing you want is agitated users breathing down your neck while you work. Maybe the error-handling code in your tools could automatically provide some kind of postmortem data snapshot mechanism to make things really easy.

So kludges have their place - they let the user get on with their job. But whatever you do, don't allow multiple kludges to accumulate to the point that certain tasks become voodoo. As soon as a proper fix is in place, make sure the kludge is killed off!

You should also treat user mistakes as bugs. If one person made the mistake, then others probably will too. And they'll come and hassle you every time it happens. So try and figure out how you can bulletproof things to prevent human error.

Solve Problems, Not Symptoms

Don't add a feature without knowing what problem it is solving. If a user has requested a new feature, step back and make sure that it's not really just a workaround in disguise.

This relies on you having a good grasp of what task the user is actually trying to perform. All too often programmers will add features that address what they think the user is trying to do, but ends up as a superficial and ineffectual solution.

Smiles Help to Fend Off Voodoo

Smile when you get bug reports! Encourage them! If people are reluctant to come to you with bugs, a culture of voodoo workaround is likely to develop. Rather than telling you that there is a problem, your users will just come up with crackpot workarounds that seem to work but are more likely than not to cause massive problems elsewhere.

But it gets worse. These workarounds will propagate around the team until they are accepted as the official way to do things. And nobody will question them any more. In extreme cases, this voodoo can infect new projects, even ones using completely different tools.

For example, on a project I once worked on, artists got into the habit of routinely using the "Freeze Transforms" tool in Maya to work around a particular unsolved issue in the exporter. The next project used a different export pipeline, but the practice persisted. And we ended up with silly, silly geometry, such as 1-metre-square objects offset from their origin by 2 kilometres. That made for some big bounding spheres and culling that was... umm... non-optimal. And the worst thing was that it wasn't visually obvious, so nobody would immediately realise why things were running slower than they should be.

So make sure you bite your tongue, grit your teeth and smile when people come to you with bug reports. You'll save yourself pain in the long run.