No, contractors are usually not a great fit for a few reasons.
1. They're expensive. A lot of can cost a 50% to 100% premium on a salaried employee. Example most good contractors I know (solid, quality devs not rockstar architects) go for about $125 an hour in the SF Bay Area. Over 48 (assume some timeoff) weeks this is about $240,000 a year. This gets worse working startup hours where you get a cost efficiency with salaried employees when people work massive amounts of overtime. Imagine the quality of engineer you can get for $200k a year.
2. When contractors are done all the knowledge of what they've done goes out of house. Both in terms of what you lose as well as any proprietary info that can now go into competitors hands.
3. Contractors don't have to work your hours. A lot of people aren't aware of the legal differences between a contractor and a full time employee because its very vague. But you can't just say "boom" you're a contractor and expect them to show up every day like a regular employee. Some do and if they don't complain its fine, but if you piss one off they can easily get you in trouble with the IRS and your state's labor code. If you expect an employee to show up every day, at your office and work 9 to 5, and work off your product backlog then they are by law a "full time" employee. You're expected to take out payroll taxes, workmans comp etc.
No hire a few very competent people who can adjust. Where contractors have their place is on discrete pieces of work - doing your iPhone app, performance tuning your stack etc. These are great places to have contractors come in.
Building a startup is a time when you are finding your way and you really need people who are interested in the details of your industry. People who will look at a spec and notice things missing, or improvement to be made.
I do think that hiring contract programmers can be good and I do so myself. But I limit their involvement to smaller sub-projects that can be written to spec and easily plugged into our app. I've done that with visual components, things that require specialized knowledge of an open source framework or really complex math algorithms, etc. It has worked very well in those cases.
"Contractors" are not the be-all and end-all, but in the context of the original article - Digg hired too many people - it's an obvious no-brainer in hindsight to say some of those hires should have been contractors and the relationship revisited after 6 or 12 months.
Anybody who has written software knows that it is never really "done." And as a consultant you get forced into a mentality of meeting your spec requirement so you can get paid. To do otherwise you risk working on one project forever and never actually meeting your contractual requirements. It's just the nature of the business. If you understand this as a client then you can make it work to your advantage, but if not you can wind up with a huge mess.
On the contrary, actually.
You want to be able to build a company engineering culture, to be able to adapt.
You want people which have a stake in the actual outcome of the company.
You don't want your programmers only be a contract away from working for your competitor.
Also: you don't want all the contracting engineering, communicating and legal overhead.
----------------- You want to keep the expertise on your product IN-THE-COMPANY, not outside. ----------------- Much of the 'expertise' I run in to is another word for undocumented knowledge. When someone leaves - employee or contractor - stuff leaves with them.
----------------- You want to be able to build a company engineering culture, to be able to adapt. ----------------- Having written documented processes will help all people be able to get up to speed much faster - employees and contractors - and 'adapt' more easily to changing needs.
----------------- You want people which have a stake in the actual outcome of the company. ----------------- Give me some written profit-sharing agreements, open books, and the ability to veto bone-headed decisions by people above me and/or in other departments. Outside of that, what "stake" do you really have in your company?
----------------- You don't want your programmers only be a contract away from working for your competitor. ----------------- Non-competes. Not valid in all areas, but possibly more enforceable against contractors or small shops than employees. IANAL, of course, but full-time employees are also just a phone-call away from working for your competitors too.
----------------- Also: you don't want all the contracting engineering, communicating and legal overhead. ----------------- Yeah the 'overhead' of communication with people is too much. Better to just have FTEs and leave them in the dark. ???
Lastly, none of what I'd initially written was posited as an "either/or". Digg's problem was they made too many hires, then were overstaffed when the nature of their problems changed. Strategic hires and contract relationships would have been much smarter, and this is something I say certainly in hindsight with Digg, but had they asked in 2007, I'd have said the same thing.
I think it was better off eaten.
"""--- You want to keep the expertise on your product IN-THE-COMPANY, not outside. --- Much of the 'expertise' I run in to is another word for undocumented knowledge. When someone leaves - employee or contractor - stuff leaves with them."""
Then you're not doing a good job managing the company's engineering dept. Is this supposed to be an excuse for moving the experience even FURTHER away?
"""--- You want to be able to build a company engineering culture, to be able to adapt. --- Having written documented processes will help all people be able to get up to speed much faster - employees and contractors - and 'adapt' more easily to changing needs."""
You can have both written documented processes AND employees that know them by experience, instead of just some "documents" left by some contractor that some new contractor needs to decipher.
"""--- You want people which have a stake in the actual outcome of the company. --- Give me some written profit-sharing agreements, open books, and the ability to veto bone-headed decisions by people above me and/or in other departments. Outside of that, what "stake" do you really have in your company?
Early engineers in a startup like Digg was have a lot of stake in their companies. Ever heard of stock options?
"""--- You don't want your programmers only be a contract away from working for your competitor. --- Non-competes. Not valid in all areas, but possibly more enforceable against contractors or small shops than employees. IANAL, of course, but full-time employees are also just a phone-call away from working for your competitors too."""
There is much more friction involved if have some stake in the company, and also if they feel the "belong" in its culture. Heck, people even choose to work for companies offering less money that what competitors offer because they like their culture.
"""--- Also: you don't want all the contracting engineering, communicating and legal overhead. --- Yeah the 'overhead' of communication with people is too much. Better to just have FTEs and leave them in the dark. ???"""
No, the overhead of communicating with contractors is too much, the overhead of communicating with people in your company is much less. (And I can't even begin to think where you got that bizarro impression from what I wrote).
Building an MVP and iterating requires building to a (changing) vision. Contractors have an incentive to stick rigidly to a narrow, fixed specification. If you can build that spec and task it out then you may get good results, but just telling a contract developer your vision and sending them off to build it has a strong chance of ending in (expensive) tears.
I am a contract developer. I work with clients to elicit their requirements and have seen this first-hand - the projects that turn out best are the ones where I'm working with someone in-house who has development knowledge, even if it's just to manage and review.
MVP+ stage requires a lot of iterative development. Ideally, you'd want to keep the people who are helping with that, because they'd know WHY things are done the way they are. They'll be aware of the failed experiments and previous iterations. You don't want future employees making the same mistakes. The goal of the MVP+ stage is to learn as much as possible about your market and product. Letting that product learning walk out because they were contractors is probably a mistake.
OK - so don't hire employees, but contract with contractors. Seems a pretty simple problem, yet few companies I talk to want to go down that route.
"We're looking for someone who's in it for the long haul" or "we value loyalty" are some reasons I've heard from companies that won't consider contractors.
In some situations, that's probably fine. In many other cases - fast tech-driven startup-type stuff - contracting probably makes more sense for precisely this reason. The company's needs can change quickly, and having a lot of staff that don't know X but only Y is a competitive problem.
"But smart people can learn X too!" Well, yes, to a point, but probably not as well as the people at your competition may already know it. And who says all those smart people really want to learn X? If you're really switching from Y to X, some Y devs may resent that, because Y can handle the workload too. They may not put all the effort in to learning X, because they see it as a fad, or a dangerous pivot that is doomed to failure, etc.
"Smart people can learn new tech X too!" is condescendingly treating devs as interchangeable parts while damning with some praise ("but they're smart!")
"If your developers are either incapable of pivoting to a new language or flat out refuse to, then they are terrible developers."
You've just done 3 years of Rails development, fighting all those version bugs, pulling all the late nighters, getting every rock solid and scaling out to the moon. Yay! Launched, everything's great, and you're rocking it. Then your board of directors signs a deal with MS for Bing tie-in, and MS invests some money in your company, but you have to pivot to ASP.NET/C#. In 3 months.
Do you refuse? YOU TERRIBLE DEVELOPER!
What's that? You'd rather keep doing Rails, so much so that you'll quit your job and move somewhere else to get a chance to keep working on Rails projects? That describes most of the Rails devs I know, and I wouldn't say they're "terribly developers" at all. Well, a couple aren't great... :)