> But it will be your code
And your colleagues will have great difficulty figuring out how it works because there is no documentation and no community support.
And your colleagues will have great difficulty figuring out how it works because there is no documentation and no community support.
If your company has a dozen tools which need the same functionality, "rolling your own" for each codebase (or worse, copy/pasting it without being able to update them from a single place) is obviously not a good solution - the choice is between making and using an internally maintained library, or using an open source one.
I've had people cut juniors/data scientists/etc loose on a "be-all-end-all" framework and ended up with the worst code I've ever seen. Edges so sharp just looking at them will cut you. I've seen code that imports trivial things like line counting! I've even been on the response team for a security incident involving several internal packages that imported the wrong thing from the package managers! I've had to re-write important library functions for a package that was imported and deprecated, and the author just went to do something else. Libraries are great, but they are not a fire-and-forget tool. When you use them, you must use them sparingly, correctly, and securely. Importantly, you need to pray a library will be maintained over the life of your software.
"Documentation and community support" is worth absolutely, positively, nothing if the usage of the library enabled the writing of poor code. Hire better developers, and create strong coding standards at your company. Let software engineers do what they do best and choose the right place to include a library after evaluating all options. Experience level matters. Late seniors and staff+ understand the difference. New seniors, TLs, and of course braindead management love to bring in the universe on every project.
If your job is to send data over TCP to rsyslog, then you’re doing your job.
If sending data over TCP to rsyslog isn’t your primary task, then doing that is a distraction, at best. Maybe the rsyslog protocol is simple enough that writing your own function is sufficient. Maybe it isn’t.
I’ve been doing this for 28 years professionally and will often choose a library (and I _do_ typically look at the code and compare code diffs across versions on upgrade) over writing my own, because:
1. My job is not to write a task runner—so I use Sidekiq or Celery or Oban. 2. I’m not confounded by the illusion of NIH being lesser.
I will always write my own code if it’s core to what I’m doing. If it’s a sideshow, I will absolutely outsource it to a library or a compiler or whatever. Anything else in the context of the job you’re hired to do is irresponsible.
However, there is a practice known as testing that is supposed to document the business goals so that your colleagues aren't left in the dark. Hopefully you haven't skimped there, regardless of where the functional pieces came from.
Ah right, so when an architecture astronaut picks up the GoF Design Patterns book and creates a rube goldberg architecture with an interface for every. single. class., it's not going to be understandable because folks didn't understand the business goals.
So hopefully they've encoded that context in tests. Worst case, if you never learned how to read code, you can throw the implementation away and the intention will remain validatable. But if you don't have the business end of the code documented... Good luck!
I posit you lack either the experience of the imagination if you think "business context" is the only factor in the development of an unmaintainable mess.
And usually, the people having to deal with this crap are ones who have never dealt with the system in the first place, and the business people and the technical people are both gone from the company…
In some languages, these are foremost used as mixin selectors (inheritance, traits, or other composition). They are commonly overloaded to describe the object's interface. I am not the only who to have seen objects inherit from other objects, with the derived class consisting of new CAMs to provide the proper interface (in lieu of some dedicated Interface class, like in Java). Then there's a third concern about testability and how to reach methods like private and protected.
If language syntax supported these different concerns with different mechanisms (notably Python and Go have made some headway for enabling testability) including a formal definition of an interface outside of CAM-mixin selection, it would make developer's lives a lot easier and quell many of the conflicting opinions about implementation dogma.