Contractor Based Development

The last contractee I worked for had an employment model somewhat like this:

Keep a very small core group of permanent employees who maintain the application and steer its development.
Bring in short-term contract programmers to do all the new-feature additions and bug fixes.

This is different from what I see as the "typical" use of contractors (bring them in when in a crunch or when you need specialized skillsets, but otherwise rely on permanent employees).

I wasn't there long enough to get a feel for how well this model works long-term, but here are my guesses at some of the resulting forces:

Pros

Lower Labor Cost -- You don't have to provide benefits, training, etc. to contractors. Administration and other overhead costs are lower. You only have to pay them when they are in the office working; you don't have to pay them for vacations, holidays, sick leave, or "bench time".
Lower Facilities Cost -- There is no need to provide a pleasant working environment. You can pack a bunch of contractors in a leaky basement with five-year-old PCs, and they won't complain much or quit.
Just-in-time Resource Acquisition -- Bring the contractors in when you have something for them to do; let them go when they are done. There is no need to keep people busy or to plan far ahead when making hiring decisions. You don't need to lay off as many permanent employees during economic downturns.
Variety of Experience -- You can pick the brains of all the contractors who come in, taking advantage of the breadth of experience that comes from working in lots of different environments.
Responsiveness to Change -- If there is some new technology or tool you need to use, you can just bring in contractors who have the necessary skills, rather than waiting for your permanent staff to come up to speed. Contact with experienced contractors can also increase the speed at which the permanent staff picks things up.

Cons

Morale -- Permanent employees often resent the presence of contractors, due to the perception that contractors make a lot more money but do sloppy, incomplete work. It may seem that the company places little value on loyalty and experience.
Loss of Knowledge and Skills -- When contractors leave, you lose access to whatever is in their heads. It is up to the permanent employees to retain as much of that knowledge as possible. You may not have any gurus as part of the permanent staff.
Inconsistency -- Having lots of temporary employees doing all the work leads to a mish-mash of differing programming styles and techniques. Also, many contractors talk their way into jobs for which they are not really qualified, resulting in generation of lots of low-quality code before their contract terms expire.
Risk of Resource Unavailability -- During periods when contractors are in high demand, it may be difficult to get them when you need them.
Accumulation of Cruft -- To minimize the time needed to bring new contractors up to speed, it is common to keep the scope of all tasks as narrow as possible. This prevents some of the deep refactorings that would be possible if the workers knew more about the application as a whole.
Skill Assessment Catch-22 -- You need knowledgeable people to assess the skill level of outside contractors, but how can you assess the competence of the contractors if you intend hire them for skills your staff do not possess? (The intended scenario for the Responsiveness to Change advantage) You could easily end up with a HighlyPaidConsultant that is using your project as the testbed for newly acquired "skills".

(Note that the Pros and Cons are stated from the point-of-view of management. The contractors and permanent employees would have differing viewpoints.)

Discussion

How much are contractors paid compared to full-time employees, and how do benefits factor in?

Where I am (AtlantaGeorgia), the typical rates paid to contract programmers are US$30-$50 per hour. That would correspond to an annual salary of about US$60K-$100K per year, assuming 40 hours/week for 50 weeks/year. That may be a little higher than what permanent employees take home, but consider that the contractors (a) have to pay for their own health plans, life insurance, retirement plans, etc., (b) don't get paid holidays, vacations, or sick leave, (c) have additional out-of-pocket expenses that employers will take care of for permanent employees (equipment, training, transportation, relocation, etc.), and (d) are likely to be out of work much of the time. There are some superstar contractors (a.k.a. HighlyPaidConsultants) who charge a lot more per hour, but that is not the norm and they would not be the ones used by a ContractorBasedDevelopment organization to do the bulk of the development work. --KrisJohnson

From a contractor point of view, I have a hard time seeing the "Responsiveness to Change" argument. If a company has internal resources, it can quickly reassign the resources and begin the job. If a company has to hire contractor, it needs to prepare a request, evaluate bids, award the contract, and after contract award wait for the contracting company to hire or reassign personnel before the task can start. This leads to a 3 - 6 month lag from the time a company decides that something must be done and any work starts.

Good grief, why? If I want a contractor, I have to get internal signoff, but after that I'd expect somebody to arrive in the next couple of days. Are things so different in the US? We're talking about getting some experienced people into the team, not about contracting out the development of an entire project

And the responsiveness to change argument is about new technologies and skills. The assumption is tha the company would find it difficult to have people with those skills available all the time for all new skills

An organization that relies on ContractorBasedDevelopment would generally have relationships with headhunters or consulting firms who could provide qualified people within a few days. This provides responsiveness to change, and assistance in finding the right people. It's usually easier and faster to bring in a contractor than it is to hire a permanent employee.

The pros/cons listed at the top of the page are for paid-by-the-hour contractors who work at the same location as the permanent employees. If you want to get a big chunk of work done for a fixed fee, or if the contractors are off site, then the pros and cons of ContractorBasedDevelopment are different--you would lose the responsiveness and many of the other pros. -- KrisJohnson

Yes, "contractor" means something different to British and US audiences -- in the US, it seems to mean (as I understand it) a second-class employee, who doesn't get the benefits and can be fired on no-notice. In the UK it means, basically, a one-person consultancy company, which hands you VAT invoices once a month, runs 28-day credit terms and sorts out its own payroll and PAYE taxes. It's the difference between hiring a temporary employee and hiring a supplier. -- KatieLucas

I understood most US employees were employed "at will" and could be fired without notice?

Yes, but for various legal and cultural reasons, US companies are reluctant to fire permanent employees even when it is clearly the appropriate thing to do. (See TheyCanFireMe for more.) Nobody frets much about terminating a contractor's work--the temporary nature of the relationship is its most essential aspect and is accepted by all parties.

In the US, there are two kinds of independent contractors, commonly referred to as "W-2" and "1099" respectively (named after the tax-related forms filed with the government for each type.) W-2 contractors are the second-class employees, and 1099 contractors are one-person companies that operate on the terms Katie describes. The term "contractor" is also used for an employee of a firm who does work for a client of that firm. In any case, there is no reason for a 3-6 month wait in hiring one, unless your company has a byzantine procurement process. An organization that relies on ContractorBasedDevelopment would probably have a very streamlined process.