Most growing tech companies must outsource some part of development at some point. Having been on both sides of the client / contractor table, I offer this advice to CEOs selecting an outsourced dev team.

Don’t do fixed-bid projects.
Don’t tell a dev team to build something for $X in Y days. Don’t incentivize them with more cash for finishing early. No matter how limited your scope, and how easy the task seems, your team will deliver the product late, and even after it’s delivered, unexpected bugs will arise. Welcome to the Internetz.comprimé levitra

When fixed-bid projects inevitably run late, everyone is unhappy. The client won’t give more business and won’t be a good reference. The vendor makes less money with every additional day spent on the project. This is the Spiral of Doom.

Do hire contractors as Dedicated Resources.
Avoid the Spiral of Doom by hiring developers as “dedicated resources.” Pay for an entire team to work for you, full time, for one month at a time. This is expensive, but it’s the only way you’ll be able to get maximum velocity from the team. Pay at the beginning of the month and commit to one month at a time.

Find out if they follow best practices.
Good, clear code is more important than velocity and performance. Poor code early on will require expensive, embarrassing delays later on. By following best practices, you’ll know that the company you hire is truly giving you code that subsequent developers can build on. If a candidate outsourced team doesn’t follow these practices, don’t work with them. You won’t be able to change them and their code will probably suck. Examples of best practices include:

Consistent coding standards. Companies should follow some standard rules for how they code and comment. Being consistent makes the code easier to read. See an example of coding standards here.

TDD or BDD. Test-Driven Development (TDD) is essentially code that tests itself. It takes longer to write the tests and then the code than to just code alone, but the long term stability is better. Behavior-Driven Development (BDD) basically means your team will build and deploy fast, and then iterate after input from users.

Regression testing. Using a continuous integration server, your team should know how new changes cause the application to behave. Errors – or regressions – should be made visible as you create the code. This way you don’t have to wait to quality-control the code.

Frequent refactoring. Refactoring often means cleaning up and re-writing code, even if it’s working smoothly. Refactor for clarity, simplicity, and scalability.

Reviewing code. Reviews can be lightweight, automated, formal, or a combination, but they should happen often and should be part of the timeline for any build. Some practices, like pair programming, have code reviewing built-in.

Pair programming. Pair programming is when two developers simultaneously write code, often using the same monitor and sitting next to one another.

Special thanks to the ClearGears CTO, Hemant Patel, for his contribution to this post.