3 ms·

> You don’t want to take the time to learn an existing product Existing libraries can be very complex. Spending time on them is not guaranteed to pay off. When

> You don’t want to take the time to learn an existing product Existing libraries can be very complex. Spending time on them is not guaranteed to pay off. When a library is marketed as a framework, it’s a red flag, such libraries often come with a strong opinion how the software should be designed. > You’re not going to properly code and test your own solution This article is old, but still good: https://www.joelonsoftware.com/2002/05/06/five-worlds/ https://www.joelonsoftware.com/2002/05/06/five-worlds/ Different software needs different tradeoffs for quality, budget, and the rest of them. If you’re working on a tool you’ll run only once, grab the output data, and forget about the tool, you don’t need neither proper coding, not much testing. > You’re going to leave features out that you would have gotten for free Are you going to need these left features? For many real-life libraries, like https://www.boost.org/ https://www.boost.org/, you only going to use small subset of these libraries. The features you’re not using aren’t exactly free. Inflated binary size, slow compilation, tons of dependencies, complicated build setup, complicated deployment are quite common issues.

bluedino 7y ago
Some context might help my comment. A programmer who used to work here, wrote his own PHP micro-framework, instead of using one of the popular, standard ones. Instead of just using one that already existed, and taking the time to learn it, he used his own. He may have done it partially for the experience or his own desires (he was probably actually bored because we have a bad manager, but that's another discussion) We regularly find and fix bugs with this PHP framework. Had he chosen a mature, community-supported product, this wouldn't happen. There are incomplete features you would have gotten for free with other frameworks. It has maybe, 20% of the features other frameworks have, even though it has much of what we 'need'. We had to write our own password-reset email code, for example.
- Const-me 7y ago
  Other reasons are possible, too. 1. When they started, pre-existing frameworks weren’t such popular nor standard. 2. When they started, the functional requirements they had were very different from what the product grew eventually. Many software projects start small and grow. 3. Couple times in my career I worked in projects where management didn’t believe in functional specs, the requirements changed dramatically in the middle of development. With large libraries, some changes in architecture are handled by replacing the library with another one. Quite expensive to do. An in-house library can be more flexible, just because it’s less code. I’m not saying making in-house libraries was justified in your case. Maybe it wasn’t and that developer did it mostly for fun. Just the trade off is quite complicated, and your reasons are not necessarily that bad. In many cases, I think it’s technical management’s job to make the decision, i.e. evaluate alternatives, maybe allocate resources to make a prototype. Also, from the management standpoint, if a developer can write their own frameworks, there’s very high probability they can use existing ones. Maybe it makes them slightly less happy i.e. need to pay them more to compensate, but they’ll do the job. The opposite is not true, there’re people skilled at combining libraries and copy-pasting third-party code who can’t write their own code.

bluedino 7y ago

Some context might help my comment. A programmer who used to work here, wrote his own PHP micro-framework, instead of using one of the popular, standard ones. Instead of just using one that already existed, and taking the time to learn it, he used his own. He may have done it partially for the experience or his own desires (he was probably actually bored because we have a bad manager, but that's another discussion) We regularly find and fix bugs with this PHP framework. Had he chosen a mature, community-supported product, this wouldn't happen. There are incomplete features you would have gotten for free with other frameworks. It has maybe, 20% of the features other frameworks have, even though it has much of what we 'need'. We had to write our own password-reset email code, for example.

Const-me 7y ago
Other reasons are possible, too. 1. When they started, pre-existing frameworks weren’t such popular nor standard. 2. When they started, the functional requirements they had were very different from what the product grew eventually. Many software projects start small and grow. 3. Couple times in my career I worked in projects where management didn’t believe in functional specs, the requirements changed dramatically in the middle of development. With large libraries, some changes in architecture are handled by replacing the library with another one. Quite expensive to do. An in-house library can be more flexible, just because it’s less code. I’m not saying making in-house libraries was justified in your case. Maybe it wasn’t and that developer did it mostly for fun. Just the trade off is quite complicated, and your reasons are not necessarily that bad. In many cases, I think it’s technical management’s job to make the decision, i.e. evaluate alternatives, maybe allocate resources to make a prototype. Also, from the management standpoint, if a developer can write their own frameworks, there’s very high probability they can use existing ones. Maybe it makes them slightly less happy i.e. need to pay them more to compensate, but they’ll do the job. The opposite is not true, there’re people skilled at combining libraries and copy-pasting third-party code who can’t write their own code.