
Ask HN: Incentivising maintainable code from freelancers? - bizzleDawg
I&#x27;m just embarking on a fairly large webapp&#x2F;api project which I know I&#x27;m going to need to bring some a front end freelancer onboard to make a react based web-app front end (My existing team will be working on the backend).<p>I am really concerned about getting maintainable code from any freelance talent I bring in, e.g. well written SASS&#x2F;LESS. Paying for a working front end at a project price (can&#x27;t take day-rate risk at this time) doesn&#x27;t seem to incentivise writing maintainable code which my team will be able to look after for years to come.<p>Beyond asking (and praying) for maintainable code, what can I do to help increase the chances of getting better commented, maintainable code?<p>Thanks!
======
7Figures2Commas
> Paying for a working front end at a project price (can't take day-rate risk
> at this time) doesn't seem to incentivise writing maintainable code which my
> team will be able to look after for years to come.

This is a curious statement because time and materials arrangements don't
guarantee maintainable code either. Poorly managed, T&M is more likely to
incentivize billing than it is quality work product.

The keys to a successful outcome here, regardless of engagement structure,
are:

1\. Contract with an experienced freelancer with whom you've discussed the
importance of code quality and maintainability. Screen out candidates who
can't speak intelligently about these topics and can't point to real-world
examples of quality, maintainable code they've delivered.

2\. Establish clear requirements before the engagement begins and incorporate
them into your contract. A fixed-price contract can actually provide you with
more leverage in this regard, as you can tie milestone payments to code
reviews. Of course, you must perform these code reviews and take them
seriously.

~~~
bizzleDawg
I will certainly action these points - reviewed milestones seem like a solid
approach.

Many thanks!

------
insoluble
From my experience doing freelance, many clients simply don't care about
maintainable code. In fact, it requires effort on my part in trying to
convince them that it's worth their while to pay the extra time for me to
clean up the spaghetti mess I inherited or otherwise to write something with
the future in mind. I would imagine that any experienced, self-respecting
developer would naturally want to develop sustainable code. Hence, I recommend
(a) finding experienced, self-respecting developers and (b) letting them know
that taking extra time to make sustainable code is okay. Aside from that,
experience in working on or managing larger, long-term projects probably
helps. A developer who has never maintained a project for 5+ years may lack
awareness of how sustainability mistakes can happen.

------
eswat
If you keep requirement changes to a minimum during the project then that
should help get you maintainable code from your freelancer, assuming they are
competent enough to provide it.

I’m always eager to offer this to clients and I sleep better knowing I’m not
going to piss off the next developer who has to look at my work. But with
startups in particular, where requirements change every few hours, this really
gets in the way of the planning and execution needed to write maintainable and
scalable code.

------
bzalasky
Budget time for clean up after you get the deliverables. If you're bringing on
the right person, hopefully they won't leave you with pile of messy code. But
even if it's mostly clear and organized, giving them paid time to increase the
maintainability and DRY it up will pay dividends in the long run. Obviously
the trade off here is that it costs more, but that's something you'll have to
consider for yourself.

------
taprun
There are some metrics that you can certainly require. For instance, a maximum
threshold on cyclomatic complexity.

A less rigorous option is that you could require regular drops at which point
you look at the code and only agree to buy the next drop if the existing drop
meets your need.

------
1arity
if you dont want to incent them to work as maintainers, make it clear the
project is one off, and calibrate a portion of the pay on how maintainable the
code is.

if you assess maintainability when you see the code, make what you pay them
depend on how maintainable you assess it.

if you assess maintainability over the lifetime of the code pay the freelancer
a small retainer over that lifetime based on how few problems maintaining it
there were.

