News for hackers. Stuff that matters.

A comment on Never use a dependency that you could replace with an afternoon of programming. Parent comment

Re:Never use a dependency that you could replace with an aft... by scarface74 on Tuesday August 11, 2020 @04:42PM (#24125735)
I could say all of the same things about the in house tools that the “architect” wrote three jobs ago - including the bespoke ORM, object mapper, and logging framework.

Or two jobs ago where two developers who had worked at the company for 10 and 15 years respectively were maintaining a bespoke 15 year old EHR written in PowerBuilder and depended on SQL Server 2003 - in 2016.

Every company thinks they are their own special snowflake where cross cutting concerns can’t be handled by a third party.

[ Parent | on HN ]
Re:Never use a dependency that you could replace with an aft... by JackFr on Tuesday August 11, 2020 @04:54PM (#24125864)
I’ve worked with dozens of guys who loved to reinvent config and logging frameworks, because ... I don’t know why.

I suppose because it was easier than working in the actual problem domain, which they knew little about and didn’t care to learn.

[ Parent | on HN ]
Re:Never use a dependency that you could replace with an aft... by nothal on Tuesday August 11, 2020 @06:06PM (#24126577)
Herding devs to work on the boring-useful things instead of the interesting-solved things is slightly easier than herding cats.
[ Parent | on HN ]
Re:Never use a dependency that you could replace with an aft... by karmakaze on Tuesday August 11, 2020 @09:31PM (#24127787)
Funny you should bring up these as examples. I've made (1) and (3) using an existing object mapper. They were made out of limitations with JPA/Hibernate and for higher-level functionality in logging. The ORM was never sent to prod. The logging events were gold. Specific events were 'major' and filtering on a user ID in a narrow timespan could show the expected/unexpected events for the traces as a sequence diagram through all the microservice layers. Clicking on an event then searched Loggly for all logs for trace-id at time. It got to the point that non-techs were answering customer issues with it and we hardly had to check/wait for Loggly to answer.
[ Parent | on HN ]