Ask HN: How to work with bad contractors?

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.

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.

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.

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.