Every development team needs a "googler". Your team needs at least one person who's first reply to a question is "Let's do a Google search and find out."

In a well-known technical interview problem (usually attributed to Microsoft) prospective employees are asked "How many gas stations are there in the U.S.?". It doesn't matter if the interviewee's answer is anywhere close to the correct value - the purpose is to observe his or her problem solving skills and logical though processes. This question also illustrates the source of many software development disasters - developers all too often come up with answers to a problem that are ingenious, logical - and utterly wrong, instead of researching the problem.

The most obvious manifestation of this is "reinventing the software wheel" - wasting time developing yet another scripting language/security system/RPC mechanism instead of using an existing solution. Just as often (but not as visibly) it happens with business requirements - far too many organizations would rather spend days debating the format of Australian postal addresses or the starting date of the fiscal year for Japanese banks than spend a few minutes researching the correct answers on the internet.

This is why your team needs a "googler" - someone who knows that a right answer is better than a clever one. This person should be familiar with a range of online knowledge sources- Freshmeat for free software, MSDN for anything related to Microsoft, and Citeseer for Computer Science research. For business knowledge NASDAQ is a good starting point for information regarding publicly-traded competitors and partners, and for legal and regulatory information almost every government agency now has a website with at least a summary of relevant procedures and regulations.

With luck you may already have someone on your team doing this - a person who gets asked the questions nobody else knows the answer to. Best of all, "googling" is contagious - as time goes the rest of your team will get in the habit of researching correct answers instead of inventing wrong ones. Oh, and the format of Australian postal addresses? The Universal Postal Union online address format guide has the mailing address formats for almost every country in the world.

Rethinking code coverage. 100% code coverage (every code path executed by at least one test) is an enshrined part of QA orthodoxy - and an outdated one.

In an iterative development process it's normal to have some unused code, either leftovers from an earlier cycle or partially-complete functionality for a future one. At the same time the shift to higher-level languages such as Java and C# reduces the likelyhood that simply executing a codepath will expose an error, unlike C where every string operation is a potential segmentation fault.

This doesn't mean there's no point in code coverage - but it's value is as an indicator of other problems rather than as an exit condition for QA. Large sections of unexecuted code may mean that your test cases don't cover all the functionality of the system, or indicate "fossil code" that developers are unwilling to delete because they don't know if it's still in use.