3rd Party Applications – a warning from history!

I’ve just been reminded about the danger of blindly using 3rd party code into the work that I’m doing.  There are a plethora of issues with just taking someone else’s work in and using it without a technical due diligence.  In this particular circumstance its going to delay the launch of a web based product for nearly a week while the offending bit of code is removed and a replacement (well checked out this time) is supplanted in its place.

It brings up the notion of what is a ‘reliable and trust worthy source’ for something that will be embedded deep inside your work.  Its quite some time since we inherited the aforementioned atrocity thats now plaguing us and the issues its causing have only just become apparent as we get into the bug fixing and optimising stages of development.  We don’t know the author of the code personally (I’m not sure if this would have protected us any) and we’re not 100% sure we understand the approach.  So we’re left with the inevitable conclusion that we have been (a) a little unlucky and (b) let ourselves down with not doing the background checking we should have when the rogue code was added to the project.

The thing that narks me personally is that I’ve been here before.  I’ve been caught out in similar circumstances from time to time and I’m old enough to know better (apparently).  The lessons learned here are:

• To not take short cuts or make presumptions on due diligence when dealing with a 3rd party.
• Make sure you have a barrier between your product and 3rd party code – a safety gate.
• Enforce coding standards on 3rd party contributors and don’t be afraid to send stuff back that isn’t up to standard.
• Don’t forget the three points above.

Still, onward and upward.