Contract Workers…Welcome to the Danger Zone

Contractors, are they good? bad? A necessary evil? There are obviously many different views on getting guns for hire to help with engineering projects. Management has to weigh pro’s and con’s of bringing someone in from outside the company to help solve the problems within. The struggling deadline for a project is perfect contractor bait. You need help, and there they are waiting for the call. Time to bring them up to the major league…

..or is it?

“But how would you phrase that?”

I’d like to play the devil’s advocate to give some insight on contractors and why I think they are usually a bad idea especially when it comes to software engineering.

1. Nine women can’t make a baby in a month
   Deadline fear can cause management to scramble and make some poor decisions. I’ve already discussed in a previous blog how adding more people doesn’t help and only makes things worse. so I won’t go over this again, but head over there and take a look.
2. The technical debt left in their wake
   Contractors are like freighters (carrying all the ridiculous amounts cash they make going from job to job) cruising through the water. Full speed ahead and they never look back to see all the other ships that have to deal with their recklessness. I wish I could even quantify the lines of code that I’ve had to rewrite because a contractor “made it work” with complete disregard for maintenance. or scalability. It’s like stabbing yourself in the leg so that the gunshot wound on your arm won’t bleed so much.
3. Scabs suck.
   Let’s be honest, no one enjoys working with a contract worker. The uneasy feeling of how in-depth you should go or time you should take training a contractor is an awful one. This is especially true if the project they work on is your pride and joy. It’s hard to find a contractor that will produce good work and be able to work well with other members of the team. Upsetting your team results in less productivity with crappier results. Skip the scabs and the crap, it’s not worth it.

Now if you truly can’t avoid using a contractor and you think the world may suddenly hurl itself into the sun if your deadline needs to be pushed back, then keep these things in mind:

1. Avoid the highways
   Certain areas of a project should be off-limits to contractors. Adding features, bug fixes, or other parts of a project that are well contained should be the playground you drop your contractors off at. Main parts of the project need to remain untainted by the hand of a rogue coder. If you don’t believe me, just wait till the loan sharks for all that technical debt come to collect. Don’t complain to me when you find your proverbial kneecaps bashed in.
2. “I’ll Never Let Go Jack“
   Let your contractors go. There is nothing worse than a lingering contractor that is costing thousands of dollars for hours of work that don’t really produce. Project and engineering managers need to have clear, set goals for the contractors to accomplish. Let them go when they aren’t needed or you can’t fit them into the project anymore. Don’t try to force them on; they knew the risk when they jumped in. Making it rain for a contractor week after week, month after month  looks really bad to your full-time engineers.
3. “THEY MAKE HOW MUCH??!”
   Contractors cost a lot, and we all know it. This seems justified because they have a reduced long-term cost and aren’t supplied benefits, etc. But honestly, it doesn’t help when salary employees see what they make. Don’t let your other engineers sign for the contractors hours worked, salary envy will ensue. This is not a good way to gain your full-timer’s trust and loyalty. Your turn over rate will suffer, big time. Full-time employees need to know they are appreciated more than the hit-men you hire. Make sure the full-time engineers’ wages and benefits are close to the contractors or you could find yourself hiring them next month as a contractor.