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.

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.

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.

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.

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]

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.

But if you disagree with it or think I left out something important, please consider leaving a reply in the comments on that page, so future readers will see your suggestions, too.

Always have your fights up front, never once the project has started. That way you'll get the project on time and under budget.

I am a little leery of not allowing the developer to provide input though. Things are going to change, you just want to narrow those changes to the important things.

Also, I think it's a good idea to invite feedback. i.e. "Here's the spec, but it's flexible. As you read and develop, be noisy if you have some ideas that could make it better."

A lot of the commenters here are advocating "give devs a vague description of goals and turn them loose". I think that's a pretty bad idea unless the product/problem is a simple/obvious one to solve OR unless the the developer has a good understanding of the market.

But even if the dev is a young superstar who has NO empathy for the customer of your revolutionary manhole cover design workflow software, you should be open to feedback.

Most people, when they try to hire me (although they don't realize it) are looking for technical or domain expert feedback. They may think they need such-and-such coded, but in reality they have a business problem that they need solved. More often than not, I can weasel out of them the business problem, and the technical solution to solve it, and it's often not at all what they originally wanted to have me do.

Part of it is that clients vastly overestimate the development time of some types of features, and vastly underestimate the complexity of other types of features, so they cut the wrong stuff from their MVP. In a sense, their project is doomed before they even hire a programmer.

Top technical talent can get and keep you on course in a way that will fix problems you don't even know you have.

I've seen a number of cases where the client spends a lot of time writing detailed requirements that are technically infeasible. They may not realize that in their simple "if x then y" statement, x is actually the result of a fifty step process involving a unicorn and a carebear making sweet love.

Every single time I paid by the hour I have had problems. I understand Derek's advice is to find one coder to work on a large project. But even then, IMHO is better to start with a fixed amount and eventually change and pay by the hour (and add other perks) only later.

Sarcasm aside, I like the "I AM REAL" suggestion to auto-filter out the guys who reply to every single job without reading. It works well on Craigslist too, to reply with a special subject tag.

The biggest reason for a developers work to slow is that they have another job. Ask the developer if they've got other work on, when it's scheduled for. If they are the type to have lots of projects on... Pass or ask that your job be their only job for a specified time.

Hiring off shore for a complicated app is simply an exercise in banging your head against the wall. You can give an identical spec to two programmers and have a great app and a piece of crap come back. Hiring offshore is bad because 1. It's harder to communicat. With them due to them not being native English speakers And 2. At least in some countries there's a culture of doing the minimum required to get the job done.

Having said that, if you are non technical and have a limited budget, I think the original article is a pretty good way to hire someone in a bad situation.

That said, once you've used them, I find it is ok to branch out a little and stick with the same person.

Still, I generally stick to branching out only a little because I find giving a web app to the "Firefox Extension Guy" might mean you are out of their sweet spot--they may not enjoy web app development which slows them down, or they may not be very proficient at it.

The problem with this is that every large development project I have seen on included a large element of what is really R&D. Most of the engineering around came in the from network admins, DBAs and sysadmins and, most of all, compilers. To roll with the analogy, the development team was designing new studs, beams, screws, and other widgets, to be produced by a (zero cost!) digital factory and later installed by a team of helpers.

This perception gap leads to all sorts of dysfunctional behavior and game playing on both sides. The example you see here is like working extremely hard to boil down your R&D to the equivalent of a one day high school lab, and then staging a contest. It will definitely give you some information, but won't solve the original problem.

Both are a produce of intellectual activity and require adequate understanding of the goal in order to streamline the product.

I differ on this, what you need is a clear road map, not people left in the dark. A feature for 2.0 may require a portion of 1.0 to be designed in a certain way, if you omit the knowledge of that feature coming down the road, you may be looking at a costly rewrite to adapt the app to that feature. Whereas the developer having for knowledge of the feature may steer them in designing the system with the though it mind that it will be coming.

you're paying multiple times for this first milestone, but it's worth it to find a good one

This is not good advice. You would be much better off combining that money and hiring a proven senior level guy, as one senior level guy can outperform a group of junior level guys. Which is what you get many times when you solicit from those sites. To be honest those sites are a race to the bottom and no senior level guys are lurking there because they have plenty of work and don't need to compete in that race.

The best advice is to break your 1.0 requirements into micro-milestones with the respective developer, the trick is to get them down to 40hr increments, for example you ask the developer do you think you can get account create / update done in 40hrs and the developer says yes with the exception of roles and permissions, or just yes, I can get that all done.

You work the contract from that perspective, they have to produce something in 40hrs and if they start going over then it becomes apparent quickly and you are rarely ever at risk of loosing more than 40hrs. This allows you to measure your risk in small increments and allows you to cut loose at the point that they start failing, while still having and completed 40hr blocks as feature complete, that you can turn over to a new developer should they start failing.

For instance, say you have 3 features in 1.0: account, orders and inventory. say the developer does account in 40hrs, submits it to you and it is feature complete, you then move on to orders and the developer misses 40 and claims that he needs 20hrs more (it happens) so you give him the 20hrs and it comes back feature complete. Now you have 2/3 done, but at any given time you where only at risk for a 40hr loss and 60hr loss when you decided to take a greater risk. Finally, say they miss inventory and claim it will take them another 40hrs, you decide that you are willing to assume 80hrs risk and it still come back defective and it will be yet another 40hrs. At this point you feel that it is too much risk so you cancel the contract, you are still in possession of 2/3 of the development effort and you can solicit for that final 1/3. As well you can opt at that point to diversify because you are loosing faith in the original developer at which point you could agree to the addition 40hrs with the original developer while hiring another developer to build the final 1/3 in parallel, in case the original developer is not able to complete the task.

One other thing to note, is when the first 40hrs is complete hire an independent party to review the architecture and the code to ensure that it is not a ball of spaghetti that will become a maintenance nightmare.

This is a far more pragmatic approach to hiring a developer.

I got my foot in the door on one job by charging the minimum for it ($50) because it involved changing one line of code (guy sent me the script for review before I bid). I'm now revamping more of that for a little bit more. But every other bid I've placed has been declined and they've accepted people who must work for $15/hr or less.

Elance is a totally depressing place, but all of our clients have us on hold so I'm looking everywhere I can.

How would you populate initially?

I can think of lots of times that I have created future-proof architecture that was never used, but I can't think of any time where there was a needed feature that couldn't be developed because of previous decisions.

That is just one example, but there are a multitude of core Architecture decision that can be affected by not knowing the entire road map. I am not saying you go out and build every hook for ever feature that will be invented but not knowing the road map is a universally bad idea.

A good example of one that we dealt with when building a reservation system for one of the big online travel companies was the idea of optimal discount pattern. The hotel industry has millions of permutations of these discounts like stay 7 nights get 2 free, or stay 5 and get 25% off or stay 4 and kids are free.

The company was fine with us adding a predefined set of these and just finding the longest duration and applying that one for the minimum viable product. We did some more digging and pressed them on this an sure enough it release 3 they where going to build out the routine to find the most optimal savings as well as the ability to add them dynamically via a rules engine. We added 10hrs to the project to make this a plug-in architecture where these patterns could be added as a plug-in. We estimated that it saved 500hrs given that all of the predefined ones where built as plug-ins and did not have to be touched or QA'ed in subsequent releases. Had we not known about that architectural need it would have been a mess to rip out that code and replace it with a plug-able architecture.

How many times has the opposite happened? Someone builds an app to be database agnostic using abstracted database layers, only to never have the system need to run on a different DBMS. I have seen this one 15 times easy as well. The abstraction for the sake of portability also has a performance hit that continues to cost.

I am not trying to argue the specifics as much as to say that when you try to code for future features, there is a pretty high error rate in knowing what those features will be and what they will need. This is especially true for startups that are likely to iterate their business model several times after 1.0.

Using the hotel example as a model, let's say that after launch the company decided that combining discounts wasn't nearly as effective as negotiating special rates with the hotels. They couldn't figure this out until after they launched, but it took them longer to figure it out because they were busy creating a dynamic rules engine instead of selling hotel reservations.

Van Halen:

Just as a little test, in the technical aspect of the rider, it would say "Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, evenly, providing nineteen amperes..." This kind of thing. And article number 126, in the middle of nowhere, was: "There will be no brown M&M's in the backstage area, upon pain of forfeiture of the show, with full compensation."

So, when I would walk backstage, if I saw a brown M&M in that bowl ... well, line-check the entire production. Guaranteed you're going to arrive at a technical error. They didn't read the contract. Guaranteed you'd run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.

The folks in Pueblo, Colorado, at the university, took the contract rather kinda casual. I came backstage. I found some brown M&M's, I went into full Shakespearean "WHAT is this before me?" ... you know, with the skull in one hand ... and promptly trashed the dressing room. Dumped the buffet, kicked a hole in the door, twelve thousand dollars' worth of fun.

The staging sank through their floor. They didn't bother to look at the weight requirements or anything, and this sank through their new flooring and did eighty thousand dollars' worth of damage to the arena floor. The whole thing had to be replaced. It came out in the press that I discovered brown M&M's and did eighty-five thousand dollars' worth of damage to the backstage area.

Well, who am I to get in the way of a good rumor?

http://www.snopes.com/music/artists/vanhalen.asp

http://www.thesmokinggun.com/archive/years/2008/1211081vanha...

But what I really wonder is how many people even could follow this advice. In the years I've been freelancing I don't think I've ever received even a single feature request that was thought out to the every click, every branch level of detail--let alone an entire application.

Personally, I've gotten burned big time hiring "talent" abroad, even utilizing a bidding and feedback system like that on getafreelancer.com, primarily due to the fact that (at least for me), it's impossible to get a foreigner psyched on a predominately American consumer product. I found that these programmers are constantly striving to provide the bare minimum, they constantly recycle code from other projects where they think it might fit (even if it doesn't), and they are desperate to close the ticket on your project and move on to the next as quickly as possible.

In my opinion, my observations fall in very closely with what Marx describes as "alienation," wherein workers (or in this case, foreign programmers) are to the extreme out of touch with what they are making. Sure, you can provide detailed documents specifying the exact nuances of what you want implemented, but you will NEVER anticipate the misunderstandings that are possible when traversing across complex language barriers, and secondly, you will never get the fit, finish, and craftsmanship that only somebody passionate about the product can imbue into it.

The second trap, of course, is to think that you can hire American freelancers, or, better yet, the "hacker" at your particular university. This, of course, comes with other disadvantages. It is often the case that university undergraduate "hackers" have several pet projects, and even in the case that they are open to discussing programming your idea, they often eventually begin to doubt whether it is worth it to essentially build your website for you (as they see it) as you sit around and tell them what to do. After all, did YOU spend the time, sweat, and endure social ostracism honing the valuable skill of computer programming as they did for years? Look no further than what happened to the Winklevoss twins at Harvard when they tried to get Zuckerberg to do ConnectU.

These arrangements almost inevitable fall through, consistently. Having been very close to entrepreneurship circles at an elite university, I can tell you that I have never once seen a non-hacker recruit a hacker to build a product successfully, though I've seen, and made, multiple attempts. The hacker's pet project ALWAYS comes first, followed by school and internships. And too many hackers, in my observation, are trying to chase the Zuckerberg dream by precluding any strong non-coding liberal arts thinkers from their teams and making all business and user experience decisions themselves. I can't speak to the success of this trend because I haven't seen the opposite case even attempted due to the pervasiveness of this hacker-centric startup attitude.

My pessimistic conclusion (though it might have a silver lining) is that unless you have a really trusting programmer friend who will help you out of your preexisting relationship, it is both not worth it to pursue hiring a programmer for your startup from abroad and not worth it to pursue alliances with your local college hacker. The best way to go is to bite the bullet and learn to code, and that way you actually have a means of effectuating your own ideas, which are liable to change, multiply, grow, etc. at a pace that you will want to control. Once you learn to code, you'll gain more respect of the hacker types anyway, and from that point you can build meaningful alliances of mutual understanding and respect. This is the route that I have taken, and I don't regret it one iota. A year into programming, I've got three iPhone applications in the store, with several more coming. The only limit for me, now, is time, and that's the only limit you really ever want to confront when building a startup. Depending on a stranger who is just doing it for money? For the birds.