3 ms·

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.

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.

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.