If you have ever worked with a developer or a development team, this article will probably strike close to home. As designers, we work with dozens of developers across the globe each year. Some of us are fortunate enough to find a gem; a developer that just gets it. A developer that you feel is on your same wavelength in terms of what needs to be accomplished with the user interface, and what it needs to happen. Most often, however, we find developers that we generally don’t see eye to eye with.
If developers only hears about bugs, problems, quirks, errors, and other issues, where’s the motivation to code? In a recent post on Joel on Software, Joel Spolsky stresses the importance of giving positive feedback to developers, not just negative. But there was no where to log my praise in our bug tracking system.
If you area technical writer who writes software documentation, chances are you have been informally involved in testing the software that you are documenting. In larger organizations, entire divisions are devoted to thoroughly testing software before it is released. In smaller organizations, this position could be informal or nonexistent. In this workshop, you will learn a basic methodology for testing software that you can use as a starting point for a new or expanded career.
I always try to get a look at a vendor's APIs before (or in the process of) evaluating a product. And I recommend you do, too. If you are involved in a product-selection effort, get input from your developers -- have them evaluate APIs as part of the product-evaluation process. Don't wait until after the deal is inked to find out whether the product's APIs are so problematic that your rollout schedule might have to undergo serious changes.