It's hard to find good developers. And new technologies - like AJAX - make i even harder. However, there are also more affordable options to connect with skilled contractors. You can ask colleages, of course; you can also post on forums and classified sites. In particular, I'd recommend trying Craigslist. Remember that with any of these choices, you'll get a ton of responses - many of which will be deceitful, incompetent, or both.



Quite often, people call me with horror stories about developers they previously employed. I'm on the high end of the payment scale - and I estimate accurately, rather than giving a low estimate and going 200-300% overbudget - so I don't always get the first call. When I get calls about terrible developers, I hear a few common problems. Let's go over them - and, of course, how to avoid them.

First, cost is difficult to analyze in intellectual pursuits. $100/hour is cheaper than $25/hour when the first gets a project done in 10 hours instead of 100. I wish I was exaggerating; in one case, the previous developer took perhaps twice as long as I would, cost twice as much, and never finished the project - as it turns out, he just modified an existing script instead of wrote it from scratch. There's nothing wrong with that, of course - all software derives from the software before - but he lacked the skills to maintain it, which is a huge problem, particularly since the script in question wasn't complicated.

What's worse is that bad execution costs you money: downtimes and badly implemented features make customers leave you for a competitor. Ideally, an outside contractor should give you a fixed fee. If you're looking for an employee, try asking for a loose estimate. Both will give you an indication of the skill of the person you're talking to.

It's difficulty to accurately measure skill, of course, but another excellent indicator is communications ability: if he can't explain the technical details of how he is going to execute your project, how is he going to get it done? Nobel award winning physicist Richard Feynman said that if you can't explain something to a high school freshman, you don't understand it.

The developer should be able to regurgitate his understanding of your project; if you get a written proposal, it should include a full description of the project. It should not be a simple bulleted list of features. The developer needs to be able to explain each piece and why it is important.

The same goes for you, too: if you don't understand your project well enough to explain every part, learn it first. You need to be able to explain every objective; you also need to understand the relative importance of each objective, and how each part relates to your profitability. Which parts are optional? Which parts are essential? Which are true requirements?

If you simply specified a required technology because it's the technology you or your staff is familiar with, you are making a mistake. If your staff can't manage the most cost effective technology, you need new staff. Drucker once said that there are two functions to a business: sales and reducing costs. If you can't use the best technology to reduce your costs, you business is, at best, performing at half capacity.

That's a subset of a bigger problem: requirements should be requirements. Clearly mark what's required and what's not. Implementation details are not requirements; "user friendly enough to be used by our target audience, 35-55 year old males who are in the fishing industry" is a requirement. "Blue buttons with accessability hotkeys" is not a requirement. Micromanagement will scare away competent developers, and will attract fools.

If an objective is desired but not required, mark it as so. If you have objectives you don't understand, you have problems unrelated to hiring. Fix them.

Last, I'd like to caution against requesting work on spec. At best, you'll get volunteers with no respect for their work. Keep in mind that all human beings want security; by treating them like dirt, you ensure that your workers will jump ship at the earliest sign of security. You don't need that; you need a stable relationship with skilled contractors and employees. As mentioned at the outset, an unskilled developers can cost you money - and unskilled developers are what you find working on spec.