Contractors Shouldn't Build Software

Why? There are two simple reasons for this.  First, a contractor has to learn about your business in order to start accomplishing anything.  Once they do there is a good chance that they will leave before the project is completely finished - and once the project is finished they will definitely leave.  Each time someone leaves, the investment you made in training must start again.  Second, the consulting model does not reward the correct behaviour.  It rewards getting the software build in the quickest time with the lowest possible budget.  It does not account for the long term cost of ownership, which can be 5 times or more of the initial project cost.

Consider:

1. The average length of time a person in the IT industry holds a job in only 2 years.
2. It takes at least 1-2 months for a development team to 'gel' and start producing good software.  Team cohesion can impact the cost and time of development by a factor of 3 to 5x.  In our experience, it will take about 6 months before the team truly gels and starts to produce quality software efficiently.
3. There is an absolute minimum time required for any software project.  No matter how many people you assign to the project, it CANNOT go any faster.  In fact, with too many people it will go slower.  This was popularized by the book "The Mythical Man-Month" published in 1975.  The key reason for this constraint is that development is limited by communication.  A 50 person team have at least 1,200 potential "communication paths". The more communication
   paths you have, the more time you spend communicating, and the more opportunities for communication
   mistakes are created.
4. Each software application has a 'documented memory' - the documentation, operation and source code of the application, and an 'undocumented memory' - the memory of the team members about how everything fits together and why it was done that way.  The 'undocumented memory' is a key factor in avoiding making the same mistake or bad assumption you made previously.
5. Maintenance fees for software averages 5 times the inital cost of development over the life of the application.  Much of this is wasted because the knowledge is lost, re-writing because it wasn't maintainable in the first place or simply getting a team to work together to work in a cohesive and productive manner.

Given these observations we find it amazing that people try to apply the 'consulting' model to building software.  In the consulting model you bring together a development team for 'version 1.0' of the software.  They organize themselves, learn how to communicate with each other, refresh their minds on the tools, learn the ins and outs of your business, then eventually get some development done and get version 1.0 out the door.  The team then disperses.  Because the timelines are tight and the budget slim the software is built only to work, not to be understood or maintainable over the life of the application.

When your business changes and the software needs to adapted to fit, you have to go through the whole process again.  But this time the team also has to labour to understand how version 1.0 was built, since the first team didn't necessarily have the time and knowledge to build it in a maintainable manner.

This is why consultants and contractors don't build good software.  Not because they are not smart people - consultants are often the most intelligent and knowledgeable people in the business.  It is because the business model is against them.  They spend so much time moving between projects and tools that they don't have the time to fully develop the skills particular to your business and your software.