Contractors Shouldn't Build Software

Why? There are two simple reasons for this.  First, a contractor has to learn a lot in order to start accomplishing anything.  Once they do there is a good chance that they will leave before the project is over - and once the project is over they will definitely leave.  Each time someone leaves, the investment 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 is much greater then 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.  In our experience, the teams' efficiency continues to grow until about the 6 month mark.
3. There is an absolute minimum time required for any software project.  No matter how many people you assign to the project, it can go no 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: communication between the business users and the analyst, the analyst and the developers, and the analyst and the quality assurance team.
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 2 years ago.
5. Maintenance fees for software averages 5 times the inital cost of development over the life of the application.  Much of this is re-training because the knowledge is lost, or re-writing because it wasn't maintainable in the first place.

Given these observations we find it amazing that people try to apply the 'consulting' model to software development.  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 the business the application is for, then eventually get some development done and get version 1.0 out the door.  Then the team disperses.  Because the timelines are tight and the budget slim the software is built only to work, not to be understood.

When version 2.0 is required 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 build, since the first team didn't 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's because time 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.  The business model works against them.