Ask HN: How to work with bad contractors?

5 points by neoburkian 7 years ago | 10 comments

I recently joined a company on a team that had a significant software project outsourced to a team of contractors. The reason for the outsourcing is that we did't have the people at the time to ship the project, and the project required deep knowledge of a non-software field that they had and we didn't.

The problem is that the contractors are just bad at writing code. The project that they have provided has all sorts of problems: functions that haven't been implemented are imported and passed as arguments through chains of functions 4-5 levels deep, every component is deeply coupled to all other components, the same operations have been reinvented in 4-5 times in different ways, etc. Whats more, the contractors seem to be convinced that the code they are shipping is pure genius.

I've brought up one of these issues in the past with the frame "can you explain why you did it this way?" and the what I got back was a word salad. How do I work with these people? What approach should I take when I bring up these deep technical debt issues?

laurentl 7 years ago |

I would suggest cutting your losses and change contractors or internalize the code. Take a look at the contract, there’s probably a reversibility clause to cover this contingency. From what you’re describing, it’s probably the best solution in the long term.

If you really want to make them improve (or if you absolutely have no other choice), I would suggest taking a look at the situational leadership model.

From the sound of it, that team is squarely in the lowest zone of autonomy. This means you have to be directive with them. Don’t try to argue or discuss, tell them what to do. Micro-manage them. Give them small tasks and check often that they’re doing what you’re telling them. Review every line of code they send your way and reject anything that doesn’t pass muster.

If this sounds like a lot of work, it is. You’re basically taking over the role of tech lead and scrum master. It may not go down well with them and it may be unenforceable. But eventually you’ll get them to a point where you can discuss with them and convince them of what should be done rather than outright telling them. This is step 2 in the STL. Your ultimate goal is to take them to step 4 (full autonomy)... Hence my first suggestion: ditch them.

mchannon 7 years ago |

Don't reason with those contractors. As far as you both should be concerned, you've hired them to write bad code, and they think they're doing a great job.

If your own internal organization is not too fat, dumb, and slow to be able to hustle during the holidays, ramp up your own staffing immediately. Sounds like the clowns you have working as contractors were always a stopgap, and now, well, it's time to stop having the gap.

To avoid a full time version of these snowflakes, and since it's caused you such pain, try sussing out the attitude of your new candidates with case examples from your existing relationship. What would they have done differently, if anything, kind of thing, and what would they do with the contractor?

The above might be a good way to gauge technical fit, interpersonal fit, and intelligence. Obviously candidates who immediately say "fire them immediately and never look back" might be a bit rash for the role, since that would leave you with no progress to show.

You have the modern-day equivalent of a Corvair (unsafe at any speed), Pinto (bursts into flames in low-speed collisions), or Diesel VW (whoops, turns out those emissions and mileage guarantees were a bit too good to be true). You can try and rework the warts, or you can call it a wash and start from scratch. Only you know which of those you need to do, but if you start hiring expert devs, they'll be able to tell you which one will take less time.

Even though their code sounds like beginner-level JavaScript, I wouldn't rule out an expert refactor based on what I've heard; as few as 5-10% of the functions getting moved around might turn your pony into a racehorse. You just need to move up to the expert.

dasmoth 7 years ago |

One thing that isn't entirely clear from this post is whether the software works. The unimplemented-functions thing doesn't sound wonderful, but I'd still argue that there's a world of difference between software that blows up the moment you look at it and something that's pretty much working except for a few loose ends where a relatively obscure feature hasn't been finished off yet.

In the former case, demonstrating that what they've done isn't "pure genius" shouldn't be too hard.

In the latter case, I think that -- especially if this is something you need reasonably quickly -- there's a good argument for focussing on value delivered and fixing actual, observable, bugs rather than spending too long worrying about the internal details. If need be, it can always be quietly rewritten once the dust has settled.

seanwilson 7 years ago |

Are you doing code reviews? They shouldn't be allowed to commit code to master until you're happy with it if it's that bad.

qualsiasi 7 years ago | |

In my company (medium size, 400 people or so and 300+ devs) code reviews are unheard of, everyone commits to the trunk. And I think this is the case in most companies.

I'm not happy, not even a bit, with this. But it's the status quo.

seanwilson 7 years ago | | |

I think for new developers to a team, you shouldn't be letting them commit to master until you've got confidence they're not going to cause problems. I've done this several times in small teams (less than 10) for new members and it's essential for orientation in my opinion so they know what the team is looking for.

UK-Al05 7 years ago | | |

I haven't been in a company that hasn't done code reviews for like 10 years now. Big and small.

I'm surprised there are areas where this isn't true.