Jun 23, 2011

Put Crowdsourced Development To Work For You

Spending time on various projects, from social games to B2B services, I work with a lot of offshore developers. Many people have heard about services like ODesk and Rent A Coder and ask me how to get started. The short answer is: carefully. The long answer is below.

Choosing Developers
Bad engineering is a mess that can take forever to clean up, if it can ever be cleaned up. Bad development practices mean everything from bad naming in database tables and code variables, to lack of scalability, to, generally speaking, code that can’t be read or maintained.

Conversely, a world-class developer can practically read your mind, seems to be always one step ahead of you, and has suggestions for both design and architecture. When it comes to offshore development, great developers treat the code and your project overall as if it were their own. They think about maintainability, scalability, and design.

Are You Technical?
This is the first and key question for many people thinking about using Odesk, Rent A Coder, or other services. If you are, you can write detailed technical specs, review code that gets written, and provide detailed feedback to developers. If you’re not, you must find someone technical you can trust to fill that role. That trusted technical peer can be an engineer you hire, or a local colleague or friend.

Have you managed a software development project? It is one thing to have someone knock out a prototype. It is another to build something scalable and maintainable.

A Clear Vision
If you have already done market or user research to confirm people want what you intend to build (see: Lean Startup!) – that is a big if – you need a clear vision of what you want to build. By clear, I mean you can write down in a sentence or two what the goal of your product is and why people will want it.

Design First, Implement Second
A clear vision also means you can draw, in pictures, the screens for your product. If you’re building a game, for example, you have clear views on the game elements, goals for the players to achieve, and specific graphics. For a web site, you have a view on everything from the overall goal, to the messages that will appear on the home page, to the flow of the site, to the individual pages and the look and feel of the buttons. Yes – all the way from the big vision down to the size, shape, and color of the Pay button. When you think product design, channel your inner Steve Jobs.

Hiring
Odds are, you will not have good success with the first developer you choose. Don’t hang on. Don’t hope it will get better. Look at the data, then act on it.

Ratings matter. Rarely should you expect to have success with an engineer who has multiple failed projects, negative reviews, or arbitrations. When choosing developers, look for those who have clocked multiple successful projects on Rent A Coder or hundreds if not thousands of positive hours on oDesk. Tempting as it may be to hire the first developer or development team that responds to your project, it’s better to wait and find greatness than settle and ultimately have to restart the project.

If you send a message to a developer and don’t hear back for days, don’t hope it’s going to get better. It’s not. If the UI of the prototype you get looks terrible, don’t assume the developer knows that and is going to tune it up. If your developer fails to pay attention to details, despite your enumerating what those details are, that developer is clearly not into the details. Again, look at the data.

If you have specific ideas – and you should – on what the UI should look like, mock up the individual screens down to the very last detail. If you don’t do this, don’t be surprised when the design you get back is not anything like what you had in mind!

Of course, the best place to find great engineers is other great engineers. Don’t settle until you find a great engineer. You will know the developer is great because the work you get back shines. It puts a smile on your face. The developer clearly takes pride in his or her work. It’s obvious. Now, ask that developer if they have friends or colleagues who are looking for work. Hire them. Some will work out, some will not. Hold onto the good ones.

A note on large development shops: although people do have success with these, you really have to get lucky. What’s more, these developers are much more likely to work a fixed schedule and not have the flexibility you need to make a project successful when you go from prototype to product. Likely you will have better success with individual developers, smaller shops, or loosely associated smaller groups of developers.

Managing The Project
To manage a real project, large or small, you must have tools: tools for communicating, collaborating, tracking, and reporting. Assembla, Basecamp, Unfuddle… there are many tools to choose from. Upload mockups to your wiki.  As items are completed, test and ticket. Stay on top of completed work, don’t let it linger. Spec out big features, but break them down into smaller pieces to get them done.

No matter what you do, you are sure to encounter The Case of The Missing Developer! No – this is not some modern day Sherlock Holmes story. This is when a developer that seems to have been making great progress disappears. No email, no code check-in, simply poof. This is because many developers on Odesk and Rent A Coder are working multiple jobs, are in school, simply lose interest, or have things happen that get in the way.

A significant challenge for developers is that they don’t know if your project is going to be around long-term so it’s hard to commit to your project full time. Once they’ve spent time working with you, and you’ve proven to be a reliable and consistent source of income and someone they enjoy working with, they’re more likely to dedicate themselves to your project 100%.

This leads to the other key aspect of project management – it’s a two-way street. Treat developers well, take the time to explain the rationale for your designs or approach, and you’re far more likely to get great results in return.

There are multiple approaches to resource management. You can do the whole project offshore. This is very hard to do unless you have worked with the team before. An excellent approach is to build the core with a local engineering team, with modules built by offshore resources. It depends on the size and scale of what you’re trying to accomplish. All that said, be clear with your expectations and then look and act on the data. If the project is not going well, it’s time to reevaluate the team, the project, or both. If it is, then scale, scale, scale!

Scaling
One of the biggest challenges every startup faces is switching from startup phase to scale phase. In the true startup phase, you’re throwing a ton of stuff at the wall all the time and seeing what sticks. Before you have users or customers in volume, you have to think about repeatability and scalability.

To think about and implement things like test and production environments, scaling, redundancy and the like, you need multiple engineers and engineers with different primary skillsets. You cannot scale on one outsourced developer and probably not even on one outsourced development team. The challenge with relying on a single outsourced team is much like the challenge of relying on a single outsourced developer: you have a single point of failure.

This is where many people who start out with ODesk, Rent A Coder, or other services run into challenges. Simply put, more scale requires more resources. It is by no means linear (Facebook: 2,000 people, 600M users), but scale requires people.

KISS
If things seem to be taking too long, you need different engineers, more engineers, or, it’s time to face the reality that your project is too complex. Go back to the KISS rule, that is: Keep It Simple, Stupid!

Complex projects stay “in the garage” for a long time. They don’t see the light of day and they fail to get user feedback. Then, when they’re put out on the market, they flop. What’s more, they’re hard to maintain and iterate. Focus on core features. Get users. Get feedback. Repeat.

Great projects, like great entrepreneurs, get feedback early and often. There is significant feature failure as they iterate and determine what works and what doesn’t.

The Timezone Challenge
Many people ask how they can communicate with engineers who are twelve hours off from them. The answer is get up early, stay up late, or do both. Document what you want done. Schedule a regular Skype call or IM catch up one to two times every week. Reliability and consistency on your end will produce the same in the developers with whom you work.

Tradeoffs
One tradeoff with offshore development is that it is that much harder to whiteboard out an idea or make a quick change. It requires more management overhead. You are dealing with different timezones and must have clarity on what you have in mind in significant detail. That does not mean writing age-old 100 page specs. It does mean, however, that a quick spec – a brief writeup in a wiki page plus a drawing, by hand or on the computer – goes a very long way.

Conclusion
Much has been written about the pro’s and con’s of using offshore development resources. Whether to use these development resources is up to you, but should you decide to, you now have one more resource to help you get started.

Services like Rent-A-Coder, eLance, and oDesk have long held the promise of distributed and efficient work resources. With communication and collaboration tools easily accessible and hosted, just like the products they’re helping to build, such promise is fast becoming a reality. Of course, building a product is only half the battle. Getting people to use it is another story!

2 Comments

  • [...] Your iPhone and Android Applications Tweet Several posts ago I talked about using offshore development resources to build an entire product. Recently, a good friend and entrepreneur contacted me about [...]

  • Great advice all around, Dave. I am just building a proper team for my project now and this was great feedback. The point I learned from the most is “Keep it Simple Stupid.” In general, I think my ideas have been overly complexed which takes a really long gestation period. Having user feedback is specially important with crowd-sourced projects so i’m learning to trim the fat quickly. Thanks again for the article.

Leave a comment