My friend Mike Smith at Hidden Path Entertainment posted this on his blog ( Elecorn ® : The Animated Coder ) a couple days ago:
When I first started programming, a bug was an indication that something was wrong with the code. While this is still true, I now look at bugs a different way. I pretty much take a “glass half full” attitude towards them.
A bug is an opportunity to make your software better. Instead of asking: “How could this happen? Who made this mistake?”, rather say: “What can we do to make our system more robust or safe so this doesn’t happen in the future”. Sometimes it’s a code fix and sometimes a process fix. But either way, finding a bug is an opportunity to improve in some way.
This attitude avoids the “quick and dirty fixes” and reduces occurrences of future bugs of the same type. It lets you focus on other areas that need work resulting in better, more stable software.
So next time you get a bug, try asking yourself “What can I do so that I handle this type of thing better in the future”?
You’ll find that you actually get excited when things break because you’ll see it as an opportunity for improvement rather than evidence of a mistake.
The applications to TA code bug fixing is obviously the same as programming. But what I find much more interesting are the applications to content bugs- and content bugs are as much the domain of the TA as they are of the content artist fixing them. Instead of just fixing a single asset, think of how a system can be built so this doesn’t happen in the future. Think of building in checks and fixes into the pipeline rather than having to hunt things down after the fact. If you have to keep doing the same thing when you fix bugs (say, compiling an animation network once the bug has been found and fixed), make sure this task is as fast and efficient as possible.
Whenever I do this, it is well worth the effort. Instead of having to figure out where a rig broke because a second rig was merged in improperly, catch it before or during the merge. Instead of relying on animators to make animations in place, determine which anims need to be in place and fix them (or ask the animator to fix them via script) automatically. Don’t treat your batch scripts as a bunch of commands, set them up as you would any other code, and they will turn into flexible automation tools instead of hacks. Check materials when you load a file to make sure they are pointing to the proper shaders and files, instead of asking artists to change them manually. Check files when you save them for things you don’t allow, such as spaces in names, capital letters, or extremely large file sizes.
Mike’s words just struck the right chord with me and I thought I’d share them and some of my personal applications of those words here.