When do you use third-party code?

Question

How do you generally resolve a programming problem, for example, when you have to parse a ini file?

If it is my task, I will :

1. First check if there is already a weapon suitable for it in my arsenal. I mean check the libraries I am familiar with, like Glib, APR, or just standard C API.

2. If I don't find anything suitable, I will check if there exist an open source library to solve this problem. I will see the quality of its API, if it has long history, what people say about it, and test it by myself.

3. If I found nothing, then I will make my own implementation. But, this situation is very rare.

In this way, I believe I can concentrate more on business, on something that is unique to our organization.

---

BUT, what I usually see a completely different approach.

1. Only believe C/C++ standard libraries.
2. Implement anything else unless it's completely impossible.

For example, when I ask my colleague, how he parse ini file, she said, "just character by character". Seems that he never considers that this problem might has been resolved by someone else.

He argues that : We are writing a commercial product, stability is most important. So we should depends on third party libraries as less as possible. And it also took time to learn new API.

---

Sometimes , I feels that this is only a personal choice depends on one's character. It's OK when people with different approach do his own job. But when they have to cooperate, one has to compromise.

What do you think about it? How do you parse .ini files?

Answer 1

I agree that looking for a solid proven solution first is a good approach, but some problems are trivial to solve with whats readily available in your language.

sscanf works nicely for parsing ini files in C.

Answer 2

I totally agree with your approach, with 1 difference: 2.5 - using the same criteria as in 2, try to find a commercial product that solves my problem. Same criteria because a number of costly mistakes taught me that a huge price sticker in itself doesn't say a thing about the quality of the code.

Answer 3

I'd rather use ready INI parser (for C - e.g. this one, it's pretty small), than do it by hand, using sscanf or alike (it's good for simple key=value maybe, but INI files can be more complex than that).

About when to use third-party code - whenever possible. Stability is important, but that's exactly why you should try to find already-tested code, than to write same thing from scratch - e.g. you may hit some obscure edge case, which somebody else has already taken care of (and you won't lose time correcting bugs in utility code, instead of focusing on main program).

Learning the API of new library takes time, but so does writing code that does exactly the same thing. Reinventing is good for learning IMHO, but I always try to reuse as much code as possible when writing anything that should work as soon as possible (unless it's impossible; e.g. platform limitations).

Answer 4

I use third party code when I think the cost of using it is less than the cost of developing the code myself. Note that I'm not talking about just monetary cost, but overall cost in time, effort, money, limitations, etc.

Answer 5

It really depends, I put the situation into a scale. If writing it by myself will take less than 10mins and there is not much space for improvement I never lookup for some other solution. However, if the task is long I check availability of reliable libraries which does the job, and nothing else. Also, if this system will needed to be integrated to other systems I try to write by myself. I hate running into compatibility problems.

Sometimes there are really good solutions to some problems. They cannot be skipped. Most of the time I prefer solutions that stays by themselves which are isolated and does not require any additional dependencies. I try to prefer libraries which are both unit and field tested. I always try to avoid adding frameworks or libraries that add too much complexity to do a task. For instance I didn't used boost libraries for "any" implementation. That requires many files, boost headers to be in include path and there might be more dependencies.

I also agree that sometimes it takes more to learn than to write. In that case I prefer writing. Sometimes re-inventing wheel is not that bad if it will fit your systems better.

Sometimes I write a library by myself for the gain of knowledge. For instance I wrote an XML parser to be used within my graduation project. It was good learning.

Answer 6

In addition to the time and stability issues already discussed, if you're developing a commercial product, you have to be very careful about the license of the third party's code. Except for public domain code or stuff under a BSD-like license, you may find it's actually more productive to roll out your own code than opening up that can of worms.

Answer 7

It sounds like your colleague is suffering from Not-Invented-Here Syndrome, which has generally been discredited. (On the other hand, Joel has an interesting piece that takes the other side.)

Developers often don't remember that they work for a business. Keys to business are value, cost, and risk. Certainly learning a complex API is a cost, as is dealing with bugs, but I see reinventing the wheel as a cost too. Either choice has associated risks.

As I see it, except for fairly trivial cases, it is a technical manager's job to decide from a business standpoint whether the cost and risk of finding and using a third-party component outweighs the cost and risk of writing the functionality in-house.

My own take is that I'll go third-party when the functionality has either been widely field-tested or when it's beyond the schedule and budget of my project. Reinventing the wheel is a cost that hurts my company's competitiveness.

Answer 8

My rule of thumb is that I like to fully understand as much of the code as possible. A coworker that fully understands it is just as good.

If the library is simple enough to read and understand, then I'll use it. If it's more complicated, the only reason I use it is if it's a very complex and commoditized problem.

For example, I would use a third-party library for an html layout engine, regular expression engine, matrix solver, SQL server, etc. I would only use a third-party library for parsing ini files if I could read it and understand it fully.

Answer 9

I think this has to do where a developer is in his career lifecycle. What I've seen from my self and other developers I talked to there are several distinct phases to developers lifecycle:

1. I will everything my self, since this is the only way I will do it right
2. I will use done components if applicable, if not I will will write it my self
3. I will use done components if applicable, If not I will not do it since is a bother to write something from scratch

Answer 10

Writing your own implementation certainly has its advantages over reusing a ready made third party module:

• The features match your need exactly. With a ready made module, this may not be the case.
• There is as little code to understand as possible, as the implementation matches your case exactly. This is a large benefit when you need to write an extension, as there is less code to understand and to modify.
• Evaluating a ready made module is very time consuming. Furthermore, some shortcomings will surface only after extensive use, when it is too late to switch to another product.
• Extending a ready made module causes a big communication overhead (discussions with the developers maintaining the ready made module). On the other hand, branching the code is untempting because you won't be able to reap benefits from bugfixes and extensions.
• All previous remarks assume the ready made module is open source. I'd never use a closed source module, as there would always be too little documentation available.

However, I'm not saying reuse is always bad. In your example of parsing an .ini file, I would recommend using the Boost Spirit parser, which allows you to define a parser with a minimum of effort.