Requirements: You

If you want your project to ship, you must already have the following items:

• Infrastructure plan for the upcoming project. Don't expect the code to compile, package, deploy, and productionalize itself. You need infrastructure to do that. If you don't have that, you will need to learn, and for this to work...

• All the documentation needs to be available in the form that is accessible to your team at all times. If you send Word documents back and forth, you are asking for a trouble. You will have diverging versions floating around, you will lose the changes and the dog will at some point eat somebody's homework. Confluence, GitHub, any other wiki-based system, or Google Docs, even SharePoint! If you are afraid that wiki is the place where the documentation goes to die, yes, it is that place, but for this brief amount of time your documentation is still alive, you will be able to reach it without building a document version control in your head as you go through hundreds of E-Mails. You can put your company logo on the front page later and make a PDF out of it. And since the best documentation is the code itself...

• Once the coding phase starts, all the development work MUST be checked in to your version control system. Remember, the code does not exist until it is checked in. This not only increases visibility in the development process, it also allows the team members on your side to anticipate the infrastructure requirements (scripting, automation, building) that you will definitely not factor in during the setup phase. Now, the code will not be bug-free, so...

• You MUST implement formal feedback mechanism for feature requirements/defect reporting. E-Mails will be lost and misinterpreted anyway. Everybody will be at loss at the current project status if you don't do that. And you don't want to tell the management you don't know when the project will be released, remember, you had contractors because you wanted to ship in time. Use the bug tracking system you already have. Please, don't turn it into an Excel spreadsheet that floats around. Make it possible for team members to provide feedback right where it is needed.

Requirements: They

You spend your company's money. You are in charge. The contractors you chose MUST implement the following:

• Have clear installation instructions for all software they are going to install on your servers, if applicable. If the installation instruction involves putting stuff to /home, you already have incompetent people on board. If the installation instruction for the second server has "copy a random configuration directory from the first server", you have just violated the VCS requirement above. You cannot automate something you don't know, so an installation instruction is a MUST.

• Agree to destroy the development environment every so often (once a week?). Since you already have all the installation automated in Chef/Puppet/Ansible (right?) and AMIs/OVFs regularly baked (if you are advanced enough), you will be able to recreate the development environment without any loss. Anything that is not automated will go away. Let everybody (your team and contractor's team) learn the lack of automation the hard way.

• Be ready to commit the code to your repository. See the paragraph above for why it is important.

• Be involved in the regular feedback loop. Do code reviews, test every commit. Unless you have a team of superhumans on your end, process resistance on contractors' end will negatively affect your own team. You don't want this to happen.

• The contractors MUST be generally aware about the environment you are going to run the code in. If they randomly edit system configuration files on the server, change directory permissions and scatter leftover files across the whole filesystem, you must have hired developers that have no idea about system administration. Let them play on that development environment, but don't let them anywhere near your staging machines. Period. Make a new environment for integration, if you can.

Production?

You are happy with the integration on your development environment, and you are ready to move it to staging. And there are one or two defects that are kind of critical, but the deadline is looming. Once defects are fixed, the automation piece may need to be updated and it may take a day or two. So you think you can allow it to slip this one time and have a manual change in the server deployment and you will rectify this in production deployment...

Congratulations, you have just converted your staging environment into a developers playground. Expect the project to fail immediately. You need the staging environment to be as close to production as possible. Competent engineers would say that it must be identical to production, the software, the deployment, all the procedures. And you will lose that change, be it due to EC2 decommissioning the hardware or the DC unexpectedly catching on fire. You will be solely responsible for the production not having the fix.

Six month later than the deadline, your product finally ships. Your team knows all the negative sides of the technologies you used. You swear you will never hire contractors again.

The management has a brilliant idea of integrating your web interface with the newly released Widgets Incorporated Omnibus Service and gives you 3 months. Will you hire contractors again?

Trust, but verify

You can be fooled by the various certifications your contractors have. An advanced certificate in configuration of a Widgets Incorporated Frobnicator 3000 may not involve the knowledge of packaging software into reusable units, configuring logging rotation/sending them to the log server. It only means that once infrastructure is up and running, Frobnicator 3000 configuration will not be horrible.

Images borrowed from

• https://www.memecenter.com/fun/99475/I-Have-No-Idea-What-Im-Doing

• http://blogs.splunk.com/2015/02/09/deploying-splunk-securely-with-ansible-config-management-part-2/