
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&#x27;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&#x27;t.<p>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&#x27;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.<p>I&#x27;ve brought up one of these issues in the past with the frame &quot;can you explain why you did it this way?&quot; 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.

