Ask HN: How to work with bad contractors?

[neoburkian]

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]

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]

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]

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]

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]

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]

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.

[qualsiasi]

I would love to do so, but we're always in a hurry for this or that project. I can't tell how many times I reported to the management that this way we're worsening our codebase and piling up technical debt. But revenue is revenue, and they always tell me "next year"... this is true also for education. I've been here for five years and attended only a mandatory course on workplace safety :)

[seanwilson]

Yeah, I appreciate it's not always easy. Some thoughts: nobody should be telling management "it's done" until code review is complete (which is true, and when you do otherwise management want to push you on to the next task because they won't understand the difference), tasks should be ready for code review a couple of days before deadlines and not on the deadline, and you need to educate management that when they push unrealistic deadlines where code review is skipped then they take on a large part of the responsibility for bugs that appear now and in the future.

In other words, they need to understand that code review isn't some bonus additional task but a vital part of healthy projects.

[qualsiasi]

Problem is that most of our work (90%) has deadlines established before getting most of the specs.

I know management should not be pushing us this way - but even being a team lead I can't change this. Time and resources are always fixed and deadlines are always so short that we can't review code nor do proper test & quality.

Part of my new years resolutions is to either change this mindset, gradually of course or change job, because working like this is not giving me the right professional experience to make the next step.

[UK-Al05]

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.