Many of our engineers are embedded with our clients, working along side our client’s engineering staff as one unit — but still representing MartianCraft and the quality and standards of any of our engineers. Which can be a test for an engineer when it comes to the selection of third party code libraries.

As a company our default position is: you are better off never using third party libraries. Of course there are always exceptions to such positions, but this is our core belief and because of this the discussions we have are never “convince me not to use this” — rather we position discussions as “convince me this is better than us writing it”.

When you hold the mindset that you always need to convince the team of using a third party library — instead of them having to convince you out of using it — the negatives are removed and you begin to advocate for the strengths. There’s no need to slam the code, the library, or what it does — instead we can focus on what we might gain for using it and evaluate that against our goals.

This type of discussion is only possible because we already accept the known pitfalls of third party libraries as a group. In short, we all agree that third party libraries are prone to:

• Being the cause of unknown bugs “down the road”
• Inherently less reactive than you can be with your own code (e.g. adopting new OS features or standards)
• Once integrated, it will never be easy to remove.

In the engineering world we always caution our clients about taking on ‘technical debt’ and here we make an argument about third party libraries. Specifically that whatever you gain now in convenience or speed, will at some point need to be paid back later on. In our more than 10 years of consulting, this has never proven false.

We’ve seen clients have to take ownership of these libraries just to keep their apps functioning, and then burning two, or even three, app release cycles to refactor the library out of the app. There is, as they say, no such thing as a free lunch.

This is not to say that all third party libraries are inherently bad, nor is selecting them — rather to say that all third party libraries are best thought of as completely out of your control. (It is possible to branch an open source library, however this has its own can of worms associated with it.) And when you are building an app with third party libraries, you have to first accept giving away control of crucial components, before you can even start thinking about which third party libraries you might want to use.

For some apps, in some areas, losing this control will make sense, but for most of the apps we work on — losing this level of control will result in more problems later on, than it would have to just write the code yourself.

Which leads us to the big decision: do we give away this control?

The decision to give away control is almost always financially motivated. Because the argument to select a third party code base is one of expedience — it is just faster to drop this in than to write it ourselves. I rarely, if ever, hear the argument that the code is better than what could be done in house (can’t imagine any engineer ever saying that either).

Time is the crucial factor and whether it is time to ship, time of contractors, or time before the next funding round — time is a factor of expenses. This isn’t about reinventing the wheel, this is about whether or not you want your team to fundamentally understand every line of code, or whether you just want to drop in the things which work.

There are times when we will always advocate for libraries we don’t own or write — especially so in specialized cases like encryption. No one needs that headache. But all too often we see people fighting against using third party libraries, which leads to unproductive arguments and ultimately letting non-engineering managers make financially motivated decisions.

What we argue is simple: pretend you never want to use a third party library, and then let people try to convince you otherwise.