Mind Your Contractors

I don't like the way many corporations use contract labor, especially in the IT market. I worked as a contractor and as a full-time employee, and my experience found that most contract programmers are mediocre. There are of course some good ones. The outstanding ones have a thorough understanding of the chosen tools and best practices, sport a respectable work ethic, deliver quality results (including documentation, for all of you guys out there that were about to say, "Oh, I'm one of the good ones!"), and are truly professionals. But most don't deliver on all those categories, and they have no impetus to change because companies aren't rating their work properly. Instead, some mediocre contractors are getting by because they have a good network or have been friendly with some managers. They are not necessarily good programmers, but they're good networkers.

Where to use Contractors

I'm not sure if I just bashed or praised the mediocre contractors, but in a perfect world, here's how I see it being done. Corporations should use contractors for certain specific needs:

• To shore up temporary staffing needs on a given project
• To temporarily apply a specific set of rare skills to a given project
• To use an expert for either of the above reasons, but also as a mentor to the staff for learning new techniques/technologies

The problem I saw in the 90's was that contractors were being hired at times almost like full-time employees. They were given project management responsibilities and often a fair amount of power. That's not necessarily wrong, if the contractor is good and is the type of person willing to contibute energy to a turnover phase (teaching about and documenting their work for the full-time staffer that takes over). But many times I saw mediocre or bad contractors tasked with important tasks like system design and development. Giving bad contractors important work sets up the hiring company for lots of downstream pain.

A developer may be superficially proficient in a given tool, but still not be what you'd call an advanced developer. Some could even be certified in the tool, but not have an understanding of related necessary knowledge, have a terrible work ethic, or be a poor communicator. In an earlier post, I lamented that many developers simply haven't mastered advanced concepts and techniques like object orientation, database modeling, agile development, and relational theory. I'm not a PhD in those topics either, but I'm always pushing to learn more and I know enough to know the difference between good and bad code when I see it. Contractors in the 90's made, and some lucky ones today still make, rates in excess of $70/hr, and for the ones that don't bring to the table the advanced skills I'm talking about, that's about $40/hr too much. Many contractors fall into this category of guys that can put together a basic GUI but not really think long term about the user and how they're going to operate this screen and what they could do to make the user's life easier. And it gets worse if you look below the surface. The mediocre developer designs poor table structures and once you've got a bad database foundation, you've set yourself up for endless hassles making the GUI and business logic have to dance around that. The point here is that most developers fall into this category, and therefore by the law of averages, so do most contractors. It's not an intentional malicious thing; the market paid well and needed guys, and companies were hiring, so it happened.

The Metric System

Part of the problem is a lack of metrics in our industry. It's hard to rate the quality of someone's code unless you have the technical ability to read and understand it, and the advanced skill in that tool set to contrast the best practice solution with what the contractor devises. There's no way to rate a developer's past work without access to their code. So most of the time, the interview is based on personality match and a basic resume bullet match. Some interviews may include a technical interview too, but these are also flawed, often testing the interviewee's ability to simply memorize a tool's help file, rather than asking about how they would apply techniques to a solution; such interviews can identify blatant resume liars, but are often as much to boost to the interviewer's ego than to really test the prospective hire's aptitude for quality IT work.

Ironically, a contractor possessing a good work ethic and communication skills but flawed or dated programming practices is just as dangerous or maybe more dangerous than the stronger developer that might not be as comfortable chatting with the CIO. Guess which one is more capable of grabbing management's ear? Of getting the new project work? Of then creating more excrement in the company's systems?

Just Rewards (for the foolish)

Here are the risks you face when hiring a sub-par contractor and giving that person important development work:

• Most developers, contractors or not, have an aversion to documenting their work. When the contractor leaves, you'd better have resources skilled enough to pick up the pieces they've left behind.
• If the contractor was brought in to build a new system, they've gained valuable business knowledge (or should have) as part of the analysis process. When they walk, so does that knowledge...often to a competitor who's hiring contractors to build a system and wants someone to have business knowledge on the resume. Also, the full-timer tasked with picking up the pieces has to go through the learning again because of the contractor's likely reluctance to document.
• If the contractor didn't employ good OO design, then the code will likely be full of hardcoding and old-fashioned procedural-style logic. That might have been ok in 1990, but by 2005, these guys should know better. Polymorphism is a very powerful tool in the hands of the right developer, and it is a good solution for addressing the many custom conditions modern systems need to handle, and the business rule changes certain to follow. Systems written by guys uninterested in educating themselves on newer techniques (techniques, not necessarily languages) will be hard to maintain and prone to heavy production support, which is a poor time sink for your full-timers left holding the bag.

"Let's build a crappy system!"

There are good contractors out there. As a former contractor myself, I strived to not produce the deficiencies I mention above. I always documented my work, often with formal manuals that could be passed on to those continuing my work. And I worked to apply best practices and think of the user when designing things. I made my share of mistakes, but by and large my clients were pleased. I enjoyed working as a contractor and getting to see a variety of projects and work with different people, and I might still be doing it if the market hadn't crashed. But as a full-timer now, I'm dealing with the things I mention above. The companies that hired the contractors weren't purposefully saying, "Let's build a crappy system!" but they had no way of knowing what was going on because they didn't have the ability to evaluate the true quality of the work.