How to: Choose between Contract and Permanent developers
A lot of software companies use contractors to supplement their in-house Engineering teams, instead of hiring more permanent staff to develop a bunch of shiny new features. But how do you decide which route to take? What are the deciding factors?
Why contractors almost always are the wrong choice
The primary reason why contractors in general are a Bad Idea is that what motivates them is all wrong for a company that produces software for a living. Note that this does not extend to companies that develop in-house software, where contractors may be a fine choice, or companies that develop their software using an old-style waterfall model. Companies that operate in countries (such as France) where firing someone is so hard that “full time employment” probably means “employment for life” also may have different concerns.
Instead, I assume we are talking about modern software companies that use one of the agile methods of software development where the goal is to produce high quality, maintainable code with the highest priority saleable features as quickly as possible, without spending ages on up-front design.
It’s amazing how much people’s motivations are influenced by how they are paid:
- If a contractor is paid by the day or the hour, it is in his interest to make the project last for as long as possible rather than bring it to completion. To make matters even worse, the end of the long, drawn-out project is unlikely to see fantastic code with tons of useful comments and a comprehensive unit test library: short of professional pride, the contractor has little incentive to focus on the maintainability or supportability of the final product.
On the contrary, if the product looks good enough and the company starts selling it, soon he may find himself getting frantic calls for his time in order to support the solution he built, but which nobody else can support. The only way to avoid this situation is to spend a lot of time on reviewing the code and insisting on getting it right - which doesn’t exactly save time for the in-house developers that already have a full plate, of course.
- If the contractor is instead paid on completion of the project, the main problem is that you need to define up front what “complete” means. Which means that you can throw away all of your best practices about agile software development and start writing down detailed lists of requirements, use cases and acceptance tests that must all be met before the project is deemed complete. The problem with this approach of course is that you are committed to getting everything right up front: if you made a mistake or forgot something, your project and your budget are probably both doomed.
- Permanent staff, on the other hand, are paid on an ongoing basis, often have stock options, and are going to still be in the office when the bugs start rolling in after the software is deployed. This means that everything else being equal, the interests of your full-time employees are much more likely to be aligned with those of the company.
When are contractors the right choice?
There are of course cases where contractors can play a role - I can think of three:
If the internal team lacks expertise in some technology or tool. In situations where you need expertise that the internal team doesn’t have, the fastest way to get it can be to hire a contractor for a short period of time. The contractor can do the specialist work required and perhaps train the internal team in the basics at the same time - all much faster than if a new hire has to be made or an existing team member needs to be brought up to speed through other means.
If you need something hard and specific done. This can be a piece of database design, using a tricky API, or some other short, hard, specific piece of work. If it isn’t hard, it’s probably not worth the effort and expense of explaining the problem to someone who is only with you for a short time.
In both of these cases, the engagement should be short and well-defined. Examples could include installing and configuring a copy of BMC Atrium, setting up and tuning a new Oracle database or helping you define a schema for a new database tool.
If you need something fast and can afford to pay. If you simply cannot afford to wait for your internal development capability to build, you can hire a bunch of contractors to develop your newest gizmo. You just have to realize that you will pay a premium for doing it, and most likely will have to throw away much of the resulting code when you need to extend the project at a later date…
Contractors save money!
In spite of the above, most of the reasons for hiring contractors instead of permanent staff are to do with saving money or lowering risk:
There is no headcount in the budget. What this means is that the company or departmental budget doesn’t allow us to hire any permanent staff, so we’ll spend some of our operational budget on hiring temporary staff to get more features built. But since the motivation is all wrong, the output is likely to be all wrong too!
It is a more limited commitment. Yes, hiring a contractor is less of a commitment than hiring an employee: you can let go of the contractor very quickly if you run into cash flow problems.
The problem with this of course is that it’s a 2-way street: The contractor also thinks of it as a lesser commitment, which influences the end product in a negative manner as discussed above.
The cost is lower because we don’t pay for sick or holidays. This has to come from someone that hasn’t looked at contractor rates recently - it just isn’t true. A contractor often comes through an agency that will want a share of the fee, and the contractor needs to consider those days where he might not have any work - downtime that the company hiring a contractor pays for. A contractor often costs at least 75% more than an employee.
In summary: Hire staff, not contractors. Unless there is something crucial you don’t know. In which case you should use contractors to get stuff done and learn at the same time.
RSS
By Morten Mertner on 19 Jun 2007
By Allan Mertner on 19 Jun 2007
By Mike Atkinson on 22 Jun 2007
By Allan Mertner on 24 Jun 2007
By Tim Coote on 28 Jun 2007
By Aparry on 17 Jan 2008
By Peter on 24 Jan 2008