Introducing 2nd party

It’s always a good idea to wrap any component that we don’t own behind an interface that we do own. There are a number of benefits:

1) We can tailor/narrow the interface to expose only the behaviour that we need
2) When we choose to change the external component, we’ll only have to modify the facade code behind our interface (as long as the interface isn’t leaky)
3) We can maintain our own suite of acceptance tests that run against the external component through our wrapper to ensure that it provides the behaviour we expect. New versions of the external component should be verified using this suite before they are accepted.

So far, so good. The confusion creeps in with the definition of ownership. 3rd party code is provided by some other organisation – you don’t own it. Components developed and maintained by other teams within your own organisation don’t fit into the 3rd party category. However, if you need to speak to another team or another department to get a change made to a component, then you clearly don’t own it. Our colleagues down the hall may work for the same company as us, but that might make it even harder to get bug fixes or change requests approved.

I was working with recently with a large european client, where someone told me that they call this sort of code 2nd party. I liked it so much, I bought him a cupcake.