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.
> 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.
> 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.
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.
> > 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.
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.