One Way to Validate Outsource Partners in Development
Apr 05, 2006
by
0
Like many other application development firms - we outsource to freelance contract developers from time to time to help us expand and contract on software projects. The quality of a developer is critical to a project - even if they are just "helping out".
Over the years I've found a few ways to quickly qualify a programmer to make sure they're up to par. Today I'll just give a couple of tips that help me validate that they know what they're doing, or at least understand corporate compliance and basic deployment standards.
Get your Paper Work in Order - the NDA/Non-Compete/Work for Hire
Ok - disclaimer. Obviously I never send over the ftp/ssh user name and password until I have an NDA on hand. The NDA I use is actually a 3 part contract.
- Non-Disclosure - Confidentiality
- It covers Non-Disclosure/confidentiality of my own clients. I protect my clients and so should you. Their web applications, customer data, etc. are all secured in an encyrpted database and all employees/contracters understand that we do not disclose their confidential or other information to anyone.
- Non-Compete
- Ultimately - I don't care if my contractors are in the same business I am. Just don't still my customers or talk to them outside of our company umbrella. It's just professional and good business to make sure this is included. Last thing you want after you work hard to land a good client - is to have one of your contracters steal them from underneath your nose. This also covers your client - you don't want one of your guys/gals starting up a company that directly competes with your client - just hairy business.
- Work for Hire
- Finally - if you create is while I'm paying you - I own it. I do this for 2 reasons. One - many times we're creating a new application that we may resell or hold on the backburner until a patent is created. Well it's not that easy to sell code or get a patent for code that you don't own...even if you paid for it! Just make sure it's clear that if you pay for the code - you own it. Period. On the other hand - there are issues with patent approval if you don't have license to code. Again - make sure you own the code that you've paid for. Finally - you need to cover your clients. If you client decides later they would like to have rights to the code you've created for them - you better make sure you have rights to it too. I've seen this happen before where everything was assumed - you know what that say about ass u me ing something.
Finally - review in an email what the NDA - contract means - don't just hope that because you sent it over and they've signed it - that there is mutual understanding. It's just good to be clear on all sides to avoid heartache later.
Ok - you've taken care of the formalities with contracts, etc. now here is the second tip.
Start with a Small Web Application or Maintenance Project
In the early days - if someone seemed to fit the mold - I'd hire them on without really knowing what they could do programatically. Big mistake - you'll loose your shorts and it will cost you down the road.
I always start with a small project - perhaps a new feature to an existing website or a small application that can be built in less then a week. This allows you to get a feel for the web contractor while also ensuring you don't break the bank.
We all know that the hourly rate is irrelevant. What matters is how much a developer can do in an hour. This is the perfect time to send over some small tasks that you have a general idea on with regards to time requirements.
I remember once asking a PHP developer for a simple contact form to email. You know the user fills out their name, phone and email - and upon submit the user is sent a copy of what they submitted and the client is informed of the contact submission.
When the PHP programmer said it would take 8 hours at their steep rate - I knew he wasn't the guy. You can't charge retail to a web development firm.
By testing your new programmer with a small project or web maintenance issue - you can get a feel for their "working personality" and also test a hint of their expertise before making any ongoing committements.
Tomorrow - tip #3 - testing your contractor for knowledge of deployment standards.
Leave a comment
To leave a comment, please log in / sign up
RSS Feed
Facebook
Twitter
LinkedIn
YouTube