3 ms·

> five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transit

by lmm 1y ago

> five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transitioned to either different teams/departments or left the company altogether, the component is still well isolated, analyzable and possible to work on. This will be far more true for an external dependency - even one that's no longer actively developed - than for an internally developed component, IME. Just at the most basic level an external dependency has to have some level of documentation and at least be usable by someone other than the original author to even get picked up. > Introduction of external dependency(-ies) carry two inherent business risks: either support for dependency will be dropped, meaning you will have to either absorb maintenance burden yourself or switch dependencies, or it will introduce breaking changes, meaning you have to stick to unmaintained version or update your product code. Both situations will eventually impact your feature flow, whatever it is. Sure, you need stay up to date, potentially even take over maintenance yourself, or accept the risk of not doing so, and none of that is free. But writing an internal implementation basically puts you in the worst-case scenario by default - you have to maintain the code yourself, and it's probably less maintainable than an external codebase.

swiftcoder 1y ago
> But writing an internal implementation basically puts you in the worst-case scenario by default - you have to maintain the code yourself, and it's probably less maintainable than an external codebase This very much depends on the type of dependency we are talking about. if it's externally-facing, sure, you'll have to maintain a suitable security posture and keep up with spec/requirement changes coming in from the outside world. If it's an internal-facing dependency, it's reasonably likely that you never have to touch it again once the problem is solved. When I worked at Amazon we had internal libraries that hadn't really changed in the past decade, because they were designed to operate inside controlled environments that insulated them from the changing world outside.
- staunton 1y ago
  Would you say Log4j is an internal or an external dependency?
  - swiftcoder 1y ago
    External, unfortunately. A library that only wrote log files would be internal, but log4j is one of those open-source solutions that has fallen prey to the kitchen-sink fallacy - bundling network transport and service discovery into your logging library creates a massive attack surface that isn't strictly related to the library's stated function.
friendzis 1y ago
> > five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transitioned to either different teams/departments or left the company altogether, the component is still well isolated, analyzable and possible to work on. > This will be far more true for an external dependency - even one that's no longer actively developed - than for an internally developed component, IME. Just at the most basic level an external dependency has to have some level of documentation and at least be usable by someone other than the original author to even get picked up. Not sure if I can agree with the sentiment, especially with the "at least be usable by someone other than the original author to even get picked up." part. Components are easily usable either because they sort of adhere to the UNIX philosophy "do one thing and do it well", which makes them inherently well isolated, or they are easy to integrate, falling on the kitchen-sink end of the spectrum, making them inherently hard to isolate. I think it has more to do with the functional domain of the component, rather than source. > Sure, you need stay up to date, potentially even take over maintenance yourself, or accept the risk of not doing so, and none of that is free. The more of a kitchen-sink the component is, the more maintenance effort there is and the higher the risks. However, in my previous comment I wanted to highlight integration risks: components on the kitchen-sink end of the spectrum are more likely to break interfaces due to feature work, nudging organization towards trunk based development. It's not inherently worse or better than leaf based development, it's a compromise, however my key point remains that larger external components shift the compromise externally, which is impossible to plan. In my experience, internally-facing external components that diverge too much simply get code frozen instead of getting required support, whereas internal components get maintenance effort allocated.

by lmm 1y ago

swiftcoder 1y ago

> But writing an internal implementation basically puts you in the worst-case scenario by default - you have to maintain the code yourself, and it's probably less maintainable than an external codebase This very much depends on the type of dependency we are talking about. if it's externally-facing, sure, you'll have to maintain a suitable security posture and keep up with spec/requirement changes coming in from the outside world. If it's an internal-facing dependency, it's reasonably likely that you never have to touch it again once the problem is solved. When I worked at Amazon we had internal libraries that hadn't really changed in the past decade, because they were designed to operate inside controlled environments that insulated them from the changing world outside.

staunton 1y ago
Would you say Log4j is an internal or an external dependency?
- swiftcoder 1y ago
  External, unfortunately. A library that only wrote log files would be internal, but log4j is one of those open-source solutions that has fallen prey to the kitchen-sink fallacy - bundling network transport and service discovery into your logging library creates a massive attack surface that isn't strictly related to the library's stated function.

friendzis 1y ago

> > five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transitioned to either different teams/departments or left the company altogether, the component is still well isolated, analyzable and possible to work on. > This will be far more true for an external dependency - even one that's no longer actively developed - than for an internally developed component, IME. Just at the most basic level an external dependency has to have some level of documentation and at least be usable by someone other than the original author to even get picked up. Not sure if I can agree with the sentiment, especially with the "at least be usable by someone other than the original author to even get picked up." part. Components are easily usable either because they sort of adhere to the UNIX philosophy "do one thing and do it well", which makes them inherently well isolated, or they are easy to integrate, falling on the kitchen-sink end of the spectrum, making them inherently hard to isolate. I think it has more to do with the functional domain of the component, rather than source. > Sure, you need stay up to date, potentially even take over maintenance yourself, or accept the risk of not doing so, and none of that is free. The more of a kitchen-sink the component is, the more maintenance effort there is and the higher the risks. However, in my previous comment I wanted to highlight integration risks: components on the kitchen-sink end of the spectrum are more likely to break interfaces due to feature work, nudging organization towards trunk based development. It's not inherently worse or better than leaf based development, it's a compromise, however my key point remains that larger external components shift the compromise externally, which is impossible to plan. In my experience, internally-facing external components that diverge too much simply get code frozen instead of getting required support, whereas internal components get maintenance effort allocated.