3 ms·

People love to claim this, especially on this site, but in my experience it's the opposite. Many people like writing new code and will do it even when it's detr

by lmm 1y ago

People love to claim this, especially on this site, but in my experience it's the opposite. Many people like writing new code and will do it even when it's detrimental to the business, but 9 times out of 10 even using a "bad" dependency is far more effective than writing in-house.

freetime2 1y ago
Can I ask how seriously your company takes security vulnerabilities and licensing? I used to have a pretty lax attitude toward dependencies, but that changed significantly when I joined a company that takes those things very seriously.
- lmm 1y ago
  I've worked with many companies over the years. License management should be automatic or mostly-automatic if you're taking dependency management seriously (particularly these days where so many projects use well-known open-source licenses and everything is machine-readable metadata), and I've never seen a single in-house codebase (even at e.g. F500 financial institutions) that took security more seriously than your average open-source library.
friendzis 1y ago
Dependencies are a double-edged sword. Most vocal people work on "disposable" end of software. It's cheaper for software giants to just throw engineer-hours at rewriting piece of code that has fallen into organizational obscurity than to maintain (hehe) maintainability. There is usually no sense for small branding/webshop factories to churn out high quality, maintainable code. However, I suggest you revisit the reason why the dreaded "enterprise patterns" exist in the first place. The main reason to use these architectures is so that 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. 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. Compromise between trunk and leaf (push of dependencies vs pull of deps) is intrinsic to modularization and is always there, however with internal components this compromise is internal, rather external. > Many people like writing new code and will do it even when it's detrimental to the business, but 9 times out of 10 even using a "bad" dependency is far more effective than writing in-house. If you are a SaaS company - most probably yes as it is the short-term outcome that is determinate of business success. However, if you work in any industry with safety and support requirements on software or put the burden of long term support on yourself, long-term horizon is more indicative of business success. Remember, writing new code is almost never the bottleneck in any mature-ish organization.
- 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?

by lmm 1y ago

freetime2 1y ago

Can I ask how seriously your company takes security vulnerabilities and licensing? I used to have a pretty lax attitude toward dependencies, but that changed significantly when I joined a company that takes those things very seriously.

lmm 1y ago
I've worked with many companies over the years. License management should be automatic or mostly-automatic if you're taking dependency management seriously (particularly these days where so many projects use well-known open-source licenses and everything is machine-readable metadata), and I've never seen a single in-house codebase (even at e.g. F500 financial institutions) that took security more seriously than your average open-source library.

friendzis 1y ago

Dependencies are a double-edged sword. Most vocal people work on "disposable" end of software. It's cheaper for software giants to just throw engineer-hours at rewriting piece of code that has fallen into organizational obscurity than to maintain (hehe) maintainability. There is usually no sense for small branding/webshop factories to churn out high quality, maintainable code. However, I suggest you revisit the reason why the dreaded "enterprise patterns" exist in the first place. The main reason to use these architectures is so that 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. 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. Compromise between trunk and leaf (push of dependencies vs pull of deps) is intrinsic to modularization and is always there, however with internal components this compromise is internal, rather external. > Many people like writing new code and will do it even when it's detrimental to the business, but 9 times out of 10 even using a "bad" dependency is far more effective than writing in-house. If you are a SaaS company - most probably yes as it is the short-term outcome that is determinate of business success. However, if you work in any industry with safety and support requirements on software or put the burden of long term support on yourself, long-term horizon is more indicative of business success. Remember, writing new code is almost never the bottleneck in any mature-ish organization.

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?