12 ms·

There's a lot of truth in this post but this line of thinking also plays into our own prejudices. I do often look at third party code and think it's pretty cra

by jsankey 12y ago

There's a lot of truth in this post but this line of thinking also plays into our own prejudices. I do often look at third party code and think it's pretty crappy, but then I need to remind myself that my own code is far from perfect! More importantly, though, we tend to underestimate both how long it will take to implement something ourselves and especially how much it costs to maintain over time. If you can use third party code from a popular and active project you get a huge amount of testing, bug fixing and other maintenance from the community over time. If you implement in house then you've just given yourself an extra burden for the life of your project.

austinl 12y ago
I think it's also worth mentioning that choosing to use third party code is an opportunity for you to give back to the community. Most of the PRs on the projects I follow come from people that are using the code in their own applications. They'll find a small problem and push a fix for everyone's benefit, instead of leaving it up to the core maintainers.
- jsankey 12y ago
  Absolutely, this is why popularity of the project matters, as it means it is more likely to be tested and actively maintained. And as a good citizen you should participate! Also: if you find you need to write this non-core functionality in-house you could consider open sourcing it yourself. If you're right that this is a need not filled by existing libraries you might just find a community grows around your version to help you maintain it.
deleted 12y ago
[deleted]
dreamfactory2 12y ago
> If you implement in house then you've just given yourself an extra burden for the life of your project. If you are doing this work for an organisation, you can also argue that it is professionally irresponsible. You are certainly unlikely to be there forever to pick up the tab for that. Coding in house is a toxic line of thought endemic in mid-level developers who haven't yet had exposure to full lifecycle costs of custom code. (And ironically the problem of so many crappy libraries is precisely due to people succumbing to NIH rather than uniting around a standard solution.)
- nirvdrum 12y ago
  While I agree it'd be nice for their to be unification, rather than a fragmented set of varying libraries, the one size fits all solution tends to be a maintenance nightmare. I guess we just have wildly different experiences, but mine is such that adding a third party dependency is typically a major liability and often originates from less experienced developers. Adding a dependency is a burden. You don't have direct control over the evolution of that code. You have to keep track of the changes. If you're lucky, the library will have a changelog, but that's sorely lacking in most projects. Blindly upgrading will bite you, so if you have a product that can't suffer downtime, you really need audit that code for every upgrade. Good luck if you've determined that the version you have is sufficient, so you've locked it down, but then a security issue is found . . . winding back patches like that can be an exercise in futility. Oh, and then there's the wonderful world of transitive dependencies. NIH for everything isn't ideal, naturally. But pushing everything out to 3rd party libs has its own set of problems that in many cases are worse. In my experience, a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain.
  - dreamfactory2 12y ago
    > a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain Indeed, but this is hopefully obvious to all of us. My point is that the cost of maintenance is vastly higher than is ever really understood. Most code is written in the context of delivering a project, and here the highest cost is considered to be getting functional code out of the door (even the first set of bugs is often overlooked). I'd propose the counterintuitive and unpopular view that the cost of development is the tiniest fraction of the lifecycle cost of lines of code when you factor in things like bugs, keeping up with security, adapting to environment changes, modifications due to new requirements, and probably most importantly the multiplying effect of adding new moving parts which makes each piece of code in a solution more expensive to write and maintain than the last. I'm perfectly aware that this will seem ridiculous and in some ways it is a little aggressive to make the point, but as evidence I would consider how many work years are spent on libraries which contain a tiny part of the functionality that is contained in useful software. Therefore the trade-off, while being about the right things, is very rarely correctly sized.
wallyhs 12y ago
> If you implement in house then you've just given yourself an extra burden for the life of your project. That is true, but maintaining third-party dependencies is also a burden for the life of your project, especially if your project outlives its dependencies. It may be well worth the burden in most cases, but it is not free.
leohutson 12y ago
That depends on how much time it takes to develop and maintain the interface to the external dependency. Also, there's little risk if it's a well supported standard open source library with many users, but if it's a proprietary library or a tiny project with a small user base, what can be done to mitigate the risk of it going in a direction that is not compatible with your own use case? In the end, you may end up having to work with and maintain your own fork of the code anyway, and I doubt that it would be easier to do so than something you wrote that was tailored to your own needs.

by jsankey 12y ago

austinl 12y ago

I think it's also worth mentioning that choosing to use third party code is an opportunity for you to give back to the community. Most of the PRs on the projects I follow come from people that are using the code in their own applications. They'll find a small problem and push a fix for everyone's benefit, instead of leaving it up to the core maintainers.

jsankey 12y ago
Absolutely, this is why popularity of the project matters, as it means it is more likely to be tested and actively maintained. And as a good citizen you should participate! Also: if you find you need to write this non-core functionality in-house you could consider open sourcing it yourself. If you're right that this is a need not filled by existing libraries you might just find a community grows around your version to help you maintain it.

deleted 12y ago

[deleted]

dreamfactory2 12y ago

> If you implement in house then you've just given yourself an extra burden for the life of your project. If you are doing this work for an organisation, you can also argue that it is professionally irresponsible. You are certainly unlikely to be there forever to pick up the tab for that. Coding in house is a toxic line of thought endemic in mid-level developers who haven't yet had exposure to full lifecycle costs of custom code. (And ironically the problem of so many crappy libraries is precisely due to people succumbing to NIH rather than uniting around a standard solution.)

nirvdrum 12y ago
While I agree it'd be nice for their to be unification, rather than a fragmented set of varying libraries, the one size fits all solution tends to be a maintenance nightmare. I guess we just have wildly different experiences, but mine is such that adding a third party dependency is typically a major liability and often originates from less experienced developers. Adding a dependency is a burden. You don't have direct control over the evolution of that code. You have to keep track of the changes. If you're lucky, the library will have a changelog, but that's sorely lacking in most projects. Blindly upgrading will bite you, so if you have a product that can't suffer downtime, you really need audit that code for every upgrade. Good luck if you've determined that the version you have is sufficient, so you've locked it down, but then a security issue is found . . . winding back patches like that can be an exercise in futility. Oh, and then there's the wonderful world of transitive dependencies. NIH for everything isn't ideal, naturally. But pushing everything out to 3rd party libs has its own set of problems that in many cases are worse. In my experience, a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain.
- dreamfactory2 12y ago
  > a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain Indeed, but this is hopefully obvious to all of us. My point is that the cost of maintenance is vastly higher than is ever really understood. Most code is written in the context of delivering a project, and here the highest cost is considered to be getting functional code out of the door (even the first set of bugs is often overlooked). I'd propose the counterintuitive and unpopular view that the cost of development is the tiniest fraction of the lifecycle cost of lines of code when you factor in things like bugs, keeping up with security, adapting to environment changes, modifications due to new requirements, and probably most importantly the multiplying effect of adding new moving parts which makes each piece of code in a solution more expensive to write and maintain than the last. I'm perfectly aware that this will seem ridiculous and in some ways it is a little aggressive to make the point, but as evidence I would consider how many work years are spent on libraries which contain a tiny part of the functionality that is contained in useful software. Therefore the trade-off, while being about the right things, is very rarely correctly sized.

wallyhs 12y ago

> If you implement in house then you've just given yourself an extra burden for the life of your project. That is true, but maintaining third-party dependencies is also a burden for the life of your project, especially if your project outlives its dependencies. It may be well worth the burden in most cases, but it is not free.

leohutson 12y ago

That depends on how much time it takes to develop and maintain the interface to the external dependency. Also, there's little risk if it's a well supported standard open source library with many users, but if it's a proprietary library or a tiny project with a small user base, what can be done to mitigate the risk of it going in a direction that is not compatible with your own use case? In the end, you may end up having to work with and maintain your own fork of the code anyway, and I doubt that it would be easier to do so than something you wrote that was tailored to your own needs.