Hacker News Reader

Comment by seanwilson | Hacker News Reader

> Should you write property based tests of a third party custom api if you are on a short term contract and pretty sure that no one is going to maintain the testing suite?

That sounds like you're doing their work for them. If I'm accepting risk in a contract, my major assumption would be the third party libraries I'm using are fit for purpose. You surely can't be held liable if the other contractors aren't doing their work to an acceptable standard.

View on HN

It's not quite that simple. Much of the problems of Windows reliability was from 3rd party drivers and apps (esp killer apps). They couldn't ditch the hardware or app vendors because their customers demanded them. So, Windows source was littered with all kinds of provisions to basically work around all that. They eventually forced driver analysis and safer language onto the ecosystem when that was too much. But a key part of their path to dominance and backward compatibility was working around known issues in 3rd party code.

Avoid this when possible obviously. However, it's sometimes a good idea when it's for tie-in to ecosystem that has benefits worth it.

Maintaining Windows is a very complex and special case though. I mean for most contract work you can safely assume the libraries you're going to be using are mostly bug free.

"Safely assume" is an oxymoron. Assumptions are a form of risk taking. The upside reward is that you save the cost of testing (and thus eliminating) your assumption. The (potential) downside is the complete failure of everything resting on that assumption. In many cases, the upside is small and knowable, the downside is hard to predict or contain - i.e. the worst kind of asymetric risk. Thus as a rule of thumb, assumptions are very bad practice, and should always be called out as liabilities in contract terms - e.g. "The cost of repair or rework due to any bugs found in the provided libraries shall be borne by X."

Do you have any concrete examples where a third party library turned out to be the major factor of a project failing? I've done plenty of projects that rely on a large number of at least moderately popular open source components for example and I've never once had a major problem. Obviously all assumptions carry risk, you should have good contract terms etc. but from experience this element is not a high risk at all. Clients tend to understand the elements that are out of your control. Changing requirements is a vastly higher risk for example.

Reply on news.ycombinator.com