What functionality should always be third-party? [closed]

Question

What prompts my question is this post from Jeff Atwood, and this post from Dare Obasanjo. It seems to me that there might be at least a few areas where third-party functionality is a better idea than custom code.

For example, should logging always be third-party? How about encryption? Or search?

I'm looking forward to everyone's feedback on this.

Edit: This question assumes that logging, encryption, and/or search isn't your core business.

Answer 1

Encryption should be third party most of the times, ...unless you're in the business of selling encryption systems.

Which is pretty much Mr. Atwood his point as I understood it, your core busines shouldn't be third party, so there's probably nothing that should always be third party...

Answer 2

My rule of thumb is to use (or at least consider) third-party for anything that's outside the core purpose of your business.

Encryption's always been the prototypical example of this. But it extends to other areas as well.

Writing logging code for troubleshooting during development is entirely different than writing logging code used for monitoring production systems.

It's all about choosing which areas of development actually add value to your project. Using third-party stuff removes the risk that that component is incomplete/buggy/etc. but comes with the risk that it may not be as flexible as what you need.

Another example would be developing an entire web forum for a website, when you can buy a solution for much cheaper.

Answer 3

"What functionality should always be third-party?"

None. there is always an exception or special case to overrule the egregious use of "always" when discussing an essentially engineering decision.

Further, the decision to go third party should almost never be made on basis of a given "functionality." There is no such thing as such a perfect library that you never need go anywhere else for that type of functionality.

Going third party is a decision that should be made based on

• Cost of going third party vs cost of doing it in house
• Development time required placed against deadlines (ie, it might be cheaper inhouse, but your development timeline might not allow it regardless)
• Ease of integration, debugging, maintenance, upgrade paths - it may be that you can develop something that will "do the job, but barely" inhouse vs not much more money for something that will take care of you for years to come
• Ease/cost of testing and proving - security packages are notoriously difficult to test well

However. There are some things where it's really tough to believe that going in house is better. For instance, you can write a competitor to OpenGL and DirectX, and in certain applications (scientific computing, etc) there are good reasons for considering such a path. But in general you wouldn't dream of it. Even though it's "free" it's still a third party dependency, and you could end up on the skids because of a bug which only affects how you use these graphics languages.

In other words, some incredibly complex or hard to prove/test things exist which should almost always go to a third party. Security is another one. Don't write your own hashing algorithm unless you are 1) certifiably crazy and 2) have at least 3 excellent business reasons to do so.

But "What functionality should always be third-party?" None. There's always an exception.

-Adam

Answer 4

I fully agree that encryption should only be done by experts whenever possible. It should also be open source and have undergone a good deal of peer review.