When do you use third party code?
How do you usually solve a programming problem, for example when you need to parse an ini file?
If this is my task, I will:
-
First, check if I have a weapon in my arsenal that is suitable for it. I mean checking for libraries that I'm familiar with like Glib, APR, or just the C standard API.
-
If I don't find anything that works, I'll check if an open source library exists to solve this problem. I will see the quality of my API if it has a long history of what people say about it and check it out for myself.
-
If I don't find anything, I'll make my own implementation. But this situation is very rare.
Thus, I believe that I can focus more on the business, on something unique to our organization.
BUT, what I usually see is completely different.
- Just trust the C / C ++ standard libraries.
- Implement something else if this is not possible.
For example, when I ask my colleague how he parses the ini file, she said "just character by character." He never seems to think that this problem can be solved by someone else.
He claims that: We are writing a commercial product, stability is important. Therefore, we should be as little dependent on third-party libraries as possible. And it also took a while to learn the new API.
Sometimes I feel like it's just a personal choice depending on one character. It is normal for people with different attitudes to do their own work. But when they have to cooperate, they have to compromise.
What do you think about this? How do you parse .ini files?
source to share
It looks like your colleague is suffering from the Not-Invented-Here Syndrome , which has usually been discredited. ( Joel , on the other hand, has an interesting piece that takes the other side .)
Developers often don't remember that they are working for a business. The keys to business are cost, cost, and risk. Of course, learning a complex API is cost as it deals with bugs, but I see how to reinvent the wheel as cost. Any choice is associated with risks.
As I see it, except in rather trivial cases, the task of the technical manager is to decide from a business point of view whether the cost and risk of finding and using a third party component depends on the cost and risk of writing functions in -d.
My own opinion is that I will go as a third party developer if this functionality has either passed extensive testing or when it goes beyond my project's schedule and budget. Rethinking the wheel is a cost that hurts my competitiveness at the company.
source to share
In addition to the timing and stability issues already discussed, if you are developing a commercial product, you must be very careful about the third party code license. With the exception of public domain code or material licensed like BSD, you may find that it is actually more efficient to use your own code than to open this worm from worms.
source to share
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 series of costly mistakes taught me that a hefty price tag alone doesn't tell you the quality of the code.
source to share
Writing your own implementation certainly has its advantages over reusing a ready-made third-party module:
- The functions are exactly tailored to your needs . This may not be the case with a ready-made module.
- There is as little code to understand as possible, as the implementation exactly matches your case. This is a big advantage when you need to write an extension, as less code is required to understand and modify the code.
- Assessing a finished module takes a lot of time . In addition, some disadvantages will only arise after widespread use, when it is too late to switch to another product.
- Expansion of a ready-made module causes high communication costs (discussions with developers supporting the ready-made module). On the other hand, forking code doesn't need attention because you won't be able to benefit from fixes and extensions.
- All the previous comments assume that the finished module is open source . I would never use a closed source module as there would always be little documentation available.
However, I am not saying that 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 the parser with a minimum of effort.
source to share
It really depends, I scale the situation. If writing on its own takes less than 10 minutes and I don't have much room for improvement. I have never looked for any other solution. However, if the task is long, I check for reliable libraries that do the job and nothing else. Also, if this system needs to be integrated into other systems, I will try to write it myself. I hate compatibility issues.
Sometimes there are really good solutions to some problems. They cannot be missed. Most of the time, I prefer solutions that stay on their own, that are isolated and don't require any additional dependencies. I try to give preference to libraries that are tested both at the level and in the field. I always try to avoid adding frameworks or libraries that are too complex to complete the task. For example, I have not used boost libraries for "any" implementation. This requires a lot of files for the header headers to be included in the include path and there may be more dependencies.
I also agree that sometimes it takes more learning than writing. In this case, I prefer to write. Sometimes reinventing the wheel isn't too bad if it fits your systems better.
Sometimes I write a library to gain knowledge. For example, I wrote an XML parser that will be used in my graduation project. It was good training.
source to share
My rule of thumb is that I like to fully understand as much code as possible. An employee who fully understands this is just as good.
If the library is simple enough to read and understand, I'll use it. If it's more complicated, the only reason I use it is because it's a very complex and commoditized problem.
For example, I would use a third party library for html layout engine, regex 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 completely.
source to share
I think this should be done when the developer is in their career lifecycle. What I've seen from myself and other developers I've talked about is there are several different stages in the developer lifecycle:
- I'll be my everything, as this is the only way to get it right.
- I will use off-the-shelf components if applicable, if not I will write myself.
- I will use ready-made components, if applicable, if not, I will not do this, since I want to write something from scratch
source to share
I would rather use a ready-made INI parser (for C - eg this one , it's rather small) than doing it manually using sscanf
or similar (this is good for simple key=value
, maybe, but INI files can be more complicated than that).
When to use third-party code - when possible. Stability is important, but that's why you should try to find already tested code rather than writing the same thing from scratch - for example, you might run into some obscure edge case that someone else took care of (and you won't waste time fixing errors in the utility code, instead of focusing on the main program).
Learning the API of the new library takes time, but it also writes code that does the same. Reinventing is good for learning IMHO, but I always try to use as much code as possible when writing anything that should work as soon as possible (if that isn't possible, like platform constraints).
source to share