Leave off all details that the programmer doesn't need to know.
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've spent the last couple of weeks looking for work on Elance, things have been pretty slow. There are some good people there (one of my old co-workers introduced me to it), but it's easy to lose them in the mass of offshored firms. It doesn't help that most people who post bids there only care about the price and will go with the cheapest one, which is the offshored firms.
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.
Thanks, your musing gave me a great idea for a site. I just registered the domain name igi.gs (if only you could do 2 letter domain names gi.gs would have been awesome). My idea is invitation only freelance site where members have to invite new members and new members have to have a proven track record, its real loose in my mind right now, but I think I am on to something, all the other offerings in this area are a crap shoot. Maybe some form of bare minimum rate as well so it does not become a race to the bottom.
If you want to share them, I am all ears. I am working on how I would seed the site now. My initial thought was to target reputable blogging freelancers and make them the initial group. I was also thinking that maybe also allowing open enrollment, but only allowing open enrollment individuals to bid for extremely small projects (under $500, so if the minimum allowable rate is $50hr then 10hr projects) this would allow them to build rank slowly, as well if a member uses them for services they can up them to an invited status. As well I have formulated the idea that a member is forever linked to their invites. If you invite someone to the site and they do good your recommendation rank goes up, if they are bad your recommendation rank goes down. If it gets too low you are no longer allowed to invite people, as it gets higher you are allowed to invite more people. This has no bearing on your abilities rank (which is what gets you gigs). My other thought is new members get feed smaller projects and as their ability rank grows then they are feed larger projects. As well, I think I would go with pure rank not a pure customer satisfaction indicator one bad project can ruin an otherwise good freelancer on the site and lets face it at some point for whatever reason, you are going to run into a bad project. I think the site could make money by being a paid verification service where we would charge a fee to certify that the code is of good quality and we act as PM's to make sure the project is tracking to the schedule.
Planning now for a feature in the next version is counter to creating a MVP.
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.
I have seen it a million times. For example, version 1.0 gets build for an in house app. version 2.0 is going to be sold to other companies. In house uses Oracle, said developer uses a lot of PL/SQL only because it allowed him to shave 30 hrs of the project. Adds 100hrs to 2.0 because the logic has to be build and the database layer has to be retrofitted to existing logic, not to mentioned QA'ed stable code will now be rewritten in 2.0 so it does not have the burn in that 1.0 provided. I walked into environments where that one has happened no less that 15 times I am sure.
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.
Migrating an application from Oracle to another DBMS is not adding a feature. I would think you could have also sold the app to other companies running on Oracle. It then just becomes a cost/benefit analysis. Is it worth 100hrs?
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.
FICO blaze; We probably would have done just as well with drools. At the time it was hard to find Blaze resources, I don't know how much that has changed.
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.