Should you enforce coding practice on your third party development team?

Question

I've written up a number of guidlines on codeing practice for a third party developer. One such practice is that no vb file should build up HTML in the code behind. Any HTML should appear in ASCX or ASPX files (so our web designers don't have to learn vb). Every time they release code it contains numerous stringbuilders. How can enforce these rules while still letting the project move forward, and without coming across like a nag everytime they breech coding practice?

Answer 1

Yes ... at some point, you may need to move the code to an internal team or a different external team and it will be much easier if everyone is using the same coding guidelines.

One technique for ensuring the externally produced code meets the standards is to include some of your internal personnel in the code review before the code is accepted. The external teams will be much more careful if sloppy coding practices are delaying their reception of payments.

Answer 2

Put it in the contract, and don't pay for code that doesn't meet your standards. Remember, if you outsource your development, they work for you, not the other way around.

I'm a consultant asked to do development occasionally, and I've been asked to follow some pretty stupid practices from time to time. I'll try to talk my client out of the ones I disagree with (one demanded that there be absolutely no configuration files because they are "messy"...), but at the end of the day, it's their money, and if they really want it done that way, that's how it shall be done. Period. Anything less, and I don't get paid.

Answer 3

There probably is not an easy technical solution.

I'd subject payment to standards compliance. Make your contract specify which standards the code must abide to and don't pay until they deliver what is expected.

You could help them get you what you want by providing tools to specify violations so they can fix them, for instance.

Answer 4

Absolutely.

Unless you are paying them to write a "black box" that you will never have to maintain or extend, it is a reasonable expectation that they write code in the language and with the syntax, file organization, architectural and coding standards that you define.

As far as how to avoid appearing to be a "nag", this is really a reasonable expectation, and it should be in your contract with them -- you may need to escalate the issue with them, and make it clear that code that doesn't comply with your standards is not acceptable delivery, and you won't pay for it to be fixed.

Answer 5

I think the short answer is that you are paying them to do this, and they should follow the rules that you set.

Answer 6

This really depends on exactly what/why you are setting the standards. To tell a web developer that you cannot build ANY HTML at run time via your codebehind files can be a very limiting factor, and in some cases might even make it IMPOSSIBLE to accomplish your needed goals.

Ideally when working with third parties it is important to stress the rules that you want followed in the beginning, and then it is the third partys decision as to continue or not. If this is done and the third party doesn't raise any red-flags then it is all fair to get on them about it.

I do a lot of consulting, and have had this type of thing happen, if I can't follow the rules due to technical limitations, I'll walk away from the project.

Answer 7

Assuming you are paying them to do this third-party development, it is completely reasonable to expect conformance with your expressed standards (especially if you've written this up and distributed it formally). If they perceive it as nagging, I would look into alternative providers.

Answer 8

It really depends on your relationship with the third party developer and the laws pertaining to those kinds of relationships in your state / country.

For example, in the US there are a set of guidelines that define whether a working relationship is an employer / employee type regardless of what the people involved consider it to be.

One of the major aspects of those guidelines is who controls the work, when it's done, and how it's done. See the following links:

1. IRS guidelines on employee / contractor status: http://www.irs.gov/pub/irs-pdf/p15a.pdf

2. Recent article on Inc.com covering employee vs. contractor status. http://www.inc.com/magazine/20080901/employee-or-contractor.html

Answer 9

If you or your company are in any way responsible for the code they produce... HELL YES!

You should tell them exactly the kind of architecture and best practices they are to use, and send stuff back when they violate your requirements. You do not want a crazy big ball of mud with a nice API slapped around it. The minute you have to go in there and fix anything yourself, you'll be glad you were so hard on them. Don't worry about slowing them down. Nothing will slow the project down faster than badly written code. Do not be afraid to hold them to your standards.

Answer 10

The issue here may be that you gave them "guidelines", but actually you have a hard requirement that your webdevs not have to modify VB files. You say "should not", but it sounds like you meant "must not".

If it was a requirement from the start, and gentle approaches have failed, then you have to play hardball. Letting them ignore requirements is just Trouble. One way to raise the issue is to ask them why it is they keep doing it - maybe they need nudging to think through ways to avoid it. Maybe you have to point at the contract, scowl, and threaten to tell accounts to withhold payment.

However, if it is just a guideline, try to upgrade it to a requirement. It's possible to do this politely - say (even if it's a lie) that you failed to predict just how badly you needed it. Admitting that you are changing the rules might give them motivation to treat this as a serious need, rather than just thinking you're being picky about coding style.

If it's not possible to strengthen the guideline to a requirement (e.g. because the requirements are already signed off and they won't accept changes), you could try asking them nicely to stop doing it anyway. Ask for a change of policy, don't nag at each changeset individually.

If they won't change, well, lesson learned. You'll know for next time to make it a requirement, and you may have to mitigate by for example pairing VB programmers with your webdevs to make changes.

Answer 11

You should enforce a set of coding practices to third-party developers. They should be the same practices you are enforcing on yourself.