[youtube http://www.youtube.com/watch?v=875cwNyBqAo&w=560&h=349]
Steve Zehngut, founder of
Zeek Interactive, has lived through and heard countless developer horror stories, such as “my project went over budget,” or, “my project is way over schedule.” The reason for these failures is usually because of poor communications with developers. “Let’s face it, developers are not the best communicators,” says Zehngut, who presented at Silicon Valley Code Camp. His subject: How to hire and work with developers. The trick, he says, is to manage expectations for both the developer and the client along the way. So when he's interviewing a developer, he's asking basic questions like:
- How much do you cost?
- How do you deliver?
- Do you have a project manager on staff?
- What’s your bug reporting system?
- Do you use a project management system?
Zehngut’s more interested in
how developers answer these questions than their actual answers. When interviewing new employees, all Zehngut really cares about is their body language. Are they confident in their answers or are they squirming? It’s not important that you have all the requirements, he says, but that can you express your passion, and prove that you're able to learn.
Holding Code Hostage Some contract developers hold their code hostage as an insurance policy that they’re going to get paid. Zehngut avoids this behavior himself as it does his client no good. “That never turns into a good situation. It’s just not a good client relationship,” he says. Whenever he starts a project he gives his client complete access to his code. It’s a controversial decision with which many other developers don’t agree. But, Zehngut says, “I’m much more interested in business and earning future business than holding code hostage.” The insurance is really for clients. It gives them a level of security. Should anything happen to Zehngut and his team they can take the code to another group. He qualifies this “open code policy” by saying it's only appropriate if you’re in a “work for hire” situation. If you own a portion of the product, you shouldn’t be releasing the code.
