I am the developer in this situation right now. I was hired by a small company as their sole developer to write them a program. So far, I have to say I pretty much disagree with everything said here.
I think the developer really needs to know the details of the domain and problem space. The company I am working for is a workforce management consulting firm. The first week on the job I interviewed 10+ consultants with the company. Got to know their tasks, goals, accomplishments, needs and pain points. I also shadowed in on one consultant for a day, and read a lot of literature. I know an awful lot now what it means to do work force management and workforce management consulting. This is helpful, very helpful. I become a knowledgeable user of the very system I am creating. Imagine if Adobe's developers had no clue about image editing, Photoshop would have been a disaster.
This feeds into my other point. Don't give the developer detailed descriptions of every click, button, error, etc. Give them the exact opposite. Tell them what the system needs to accomplish, and let them design it. For one, they will almost certainly design a simpler and easier to manage system than you will (maybe not easier to user, because let's face it, that's not usually a programmer's forte). Since the developer now knows the domain pretty well, they can use that knowledge to help design an effective solution. let the developer arrive at your goal with as minimal amount of code and work as possible. That way you can see your vision in the flesh, use it, and actually start to understand what it does. Only once a feature is actually implemented and put to use do you really start to understand what it needs to do.
Maintain a dialog with your developer. Give feedback often and have the two of you work together on where the project is going.
Basically all I am saying boils down to what most agile development processes ascribe to.
I do however totally agree with doing the "simple" version 1.0 release first.
You sound like a great developer, but the reality is that you're an anomaly. Most developers suck, especially the ones on elance, rentacoder, etc. And if you're not technical, you have no idea how to figure out which ones suck. So I see this advice as being for non-technical folks who want to maximize their chance for success and limit their downside. And in that light, I think it succeeds.
But then isn't this all a recipe for disaster? If you need a piece of software to be written from scratch for you, then it's probably critical to your business. It may even literally be your business. Why in that case would you want to scrape by with a crappy coder and try and wield them to be effective? I think if that is the situation you end up in, you're better off not doing it at all.
Granted I've never done a start up, so maybe I'm just naive. But it seems like if you want to do a technical start up, you should be technically minded.
"If you need a piece of software to be written from scratch for you, then it's probably critical to your business."
G'lord, no! How much software is necessary for the minimum viable product of Groupon? Digg? TechCrunch? Facebook? Twitter? FourSquare? StackOverflow? Heck, we KNOW that Digg was outsourced, and that worked out okay. Many (maybe even MOST) startups true problem is marketing/UI/social rather than deep geekery. Many more can get by on half-assed engineering to prove out the initial assumptions and then just rewrite if they see a glimmer of success. Paul Buchheit has said that he rewrote chunks of Gmail quite a few times... It's not unusual.
There are plenty of startups where this would be a disaster but (as web apps get easier and cheaper to build) I think they are increasingly the exception rather than the rule.
Can't agree with this comment more. I realize this article is aimed at getting the best hired gun you can, but the best way to partner with a developer is to do just that - actually partner, not toss requirements over a wall. Get their advice on design decisions early on. Make them feel a part of the product's direction. Ensure they understand and are on board with what the product is trying to accomplish. Then let them run with it.
You could combine this approach with the whole "hire 3 people and see who can turn in the best result" idea. But I strongly believe that having developers who are motivated is extremely important...and the best motivation involves giving them ownership and autonomy as well as objectives.
the best way to partner with a developer is to do just that - actually partner
That was my takeaway as well. The article gives good advice on how to pick the best person on elance, but I challenge the notion that you want to look for your critical partner on elance in the first place.
I guess it's a semantics discussion: I believe in finding co-founder (http://fairsoftware.net), others believe in outsourcing their development. Both approaches are valid, they both have tradeoffs.
Outsourcing is easier to get started: you pay cash, you get someone, anyone. With co-founders, the dating could take 3 months, which sounds very frustrating at first, except it pays off for life. [insert dating analogy here]
You're assuming that you can find a programmer who is very self-motivated, cares about your project, and is willing to obsess over it (and is paid accordingly).
In the real world, giving even an above average freelance coder a vapid spec will result in something undeveloped that you both hate, even with constant feedback.
I strongly agree; a programmer that understands the problem domain and the business layer as well as the superficial "requirements" foisted upon him is about 10x more useful than one that merely follows instructions toward some sort of end that is not particularly accessible to him.
I think the developer really needs to know the details of the domain and problem space. The company I am working for is a workforce management consulting firm. The first week on the job I interviewed 10+ consultants with the company. Got to know their tasks, goals, accomplishments, needs and pain points. I also shadowed in on one consultant for a day, and read a lot of literature. I know an awful lot now what it means to do work force management and workforce management consulting. This is helpful, very helpful. I become a knowledgeable user of the very system I am creating. Imagine if Adobe's developers had no clue about image editing, Photoshop would have been a disaster.
This feeds into my other point. Don't give the developer detailed descriptions of every click, button, error, etc. Give them the exact opposite. Tell them what the system needs to accomplish, and let them design it. For one, they will almost certainly design a simpler and easier to manage system than you will (maybe not easier to user, because let's face it, that's not usually a programmer's forte). Since the developer now knows the domain pretty well, they can use that knowledge to help design an effective solution. let the developer arrive at your goal with as minimal amount of code and work as possible. That way you can see your vision in the flesh, use it, and actually start to understand what it does. Only once a feature is actually implemented and put to use do you really start to understand what it needs to do.
Maintain a dialog with your developer. Give feedback often and have the two of you work together on where the project is going.
Basically all I am saying boils down to what most agile development processes ascribe to.
I do however totally agree with doing the "simple" version 1.0 release first.