Do you use to third party companies to review your company's code?

Question

I am looking to get the following -

Basic code review to make sure they follow the guidelines imposed. Security code analysis to make sure there are no loopholes. No performance bottlenecks by doing a load test etc.

We have lot of code coming in from third parties and is becoming laborious to manage code reviews and hence looking to see if others employ such practices.

I understand that it may be a concern for some and would raise the question "Well, who is going to make sure the agency is doing their job right?" But basically I am just looking for a third party who can hold all vendor code to the same standards.

Answer 1

No

But if I really needed my code review by an "independent" eye, then I would generic-ize it and post it on codereview.stackexchange.com.

Answer 2

No way! Our code is our secret sauce (and easily copied by a third party "reviewing" the source).

If it's third-party code you want to audit on the way in, then ok I guess...

Answer 3

Yes

I even use P.SE top users for that, and I'm very happy with the result.

Because that user

• is not a part of my company,
• the quality and honesty of his answers here,
• don't know who wrote the code,
• is not involved at all in the project.

His honest feedback is very valuable to both the team and me.

Answer 4

I've never seen that practice used. One of the costs of importing code is the need to review it. If you don't do that yourselves why would you bother reviewing it at all? It's an awfully expensive way to get a second opinion that's unlikely to be much higher quality than the suppliers one.

What I have done is tripwire the reviews. We keep fairly detailed notes and our rule is that after three rewrite issues we stop reviewing and send the whole steaming pile back where it came from. We've also done it once when we got to about 50 minor points, because we felt that they needed to go through and systematically fix a few patterns we didn't like (poor use of resources, essentially).

We also demand both unit and integration tests be supplied, and we generally start our reviews there. If they're not testing against our requirements, or the unit tests are not broad enough, we send it back.

All of which increases the cost of using third party code, and creates tension with management who want cheap code. It can make it look as though we're sabotaging the external suppliers. So we deal with that by demonstrating that we use a lot of external code anyway (we use lots of FOSS + external libraries)l and by black-boxing the occasional third party developer - we write the integration tests and accept whatever passes them. That is not quite as cheap but it works when you've got a sharp subsystem boundary.

Answer 5

There are tools that you can run across the code to check it, FXCop being one example for MS based code.

Not sure if this fits with your 3rd parties, but you can build these into your automated build process and you'll have constant, current feedback.