Don’t forget outsourcers!
In the comments on post “Internal Tools Only Require the Critical Path“, Robert Kist points out a few problems to think about when developing internal tools that may have to be used by outsourcers.
I absolutely agree and writing outsource-compliant tools are something many TA’s (including myself) can struggle with. The biggest things are:
Security: Assume your users do not have administrator rights. This shouldn’t be a problem if you are doing things the “right way”, rather than the “hard-coded expedient at the moment” way.
SCM Clients: Do your outsourcers have SCM clients? If not, what does that mean if you scatter your SCM interaction throughout your tools? Are you observing best practices and trying to make your SCM interaction transactional, or are you just making calls at the earliest possible moment?
Network resources: Do your tools require access to network resources, and if so, do the outsourcers have access to them? This could be a database, or a file on the network. Consider how you can break or mock these dependencies (or get rid of them entirely).
Latency: If your tools do require network resources, are they hitting the database/network constantly? If so, expect your tools to be incredibly slow, since instead of access time measured in milliseconds over distances of hundreds of meters, expect access time requiring many seconds over several thousand kilometers. Figure out how to reduce/batch your DB calls/network IO, or mock them out (perhaps provide read-only copies on disk, and point your DB at them).
Machine setup/bootstrapping: What sort of configuration are you relying on, in terms of file setup/folder structure, and in terms of global state of the machine (environment variables, drive letters). Not building in any dependencies on global machine state ensure your tools are much more portable.
Localization/internationalization: Not every international outsourcer speaks English. Many places will translate documentation when settings things up, but that documentation can get stale. We should start thinking about writing localizable code and documentation.
Not so coincidentally- writing good code helps you make more portable tools. A lot of these problems aren’t really problems at all and they don’t really require extra work- they just require care and craftsmanship while developing your tools and code. Focusing on the critical path doesn’t give you a license to write bad code. In fact the contrary. The focus on the critical path means you should have excellent code at all times because the critical path is critical. So if you write good code, as you should, supporting outsourcers will be a lot easier when that time comes.
Do you have any experience or stories writing tools for outsourcers? I’d love to hear about them in the comments.
Biggest problems for us are indeed security (please test your tools on non admin accounts!) and network latency – especially when we have to connect from China to North American servers. Tools which require “always-on” connections are especially bothersome.
If you talk to some server in your script (P4, database, whatever) please re-check if the connection is still there before doing something. Programs not handling dropped connections is something we encounter often.
Machine setup: Please avoid intrusive setups which totally re-configure Max/Maya/the-entire-PC and make it impossible to run tools from another client afterwards. (my favorite annoyance: MAYA_APP_DIR. Use a batch file to set it and to launch Maya afterwards, don’t just change system environment variables with your tool’s installer). Uninstallers are also welcome, but if your tool isn’t intrusive, then this isn’t so high on our “want to have” list.
Interestingly enough, Localization isn’t a very big topic for us. I think the artists are used to working with English tools. We do however summarize and translate parts of the client supplied docs and also have hands-on training sessions. Translating the tools themselves would probably take more time than we can fit into our busy schedule.
Thanks Rob for putting the spotlight on this topic!
one more thing: Unicode support is also nice to have. If someone accidentally enters Chinese/Russian/etc characters as file name or in a text box in your tool, then it should be able to handle this or pop out an error msg (instead of just dying or adding garbage to your db/xml/etc).
Max scripts: extended ASCII characters break max script on non western PCs! (we then always have to change the windows system locale – annoying). Stay away from the degree sign, the copyright sign, etc. In max script stick to the characters printed on your US/western european keyboard. If you don’t see the character there, then don’t use it in the script.