Hacker News Reader

Comment by zerotolerance | Hacker News Reader

Minimizing what code you own is a naive optimization. When you consider the liabilities that third-party library and service dependencies introduce it becomes quite attractive to build your own minimal systems. I'm not sure when programmers became so averse to writing simple code. But leftpad was just the beginning.

View on HN

Maybe because so often that 'simple code' is only simple because the author is suffering from a combination of naiveté and Dunning-Kruger. Trivializing problems makes you a danger to your team, your company. Not an asset.

Deep object cloning/inspection, URL parsing/generator. Date arithmetic. Locking. Caching. Testing. Templating. I've had to rip so many of these out for being fundamentally unworkable and often wrongheaded solutions to already solved problems that it's become a cliche in my career.

I'm not trivializing problems. And I agree people writing wholly new solutions to complicated things is a hilarious cliche. I'd never say, "go write your own JSON parser." And like you said, they're already solved problems. That means there are many ways to DIY, including forking, or cloning just the parts you need.

>I'm not sure when programmers became so averse to writing simple code.

I know everyone likes to spend a day writing a date/time library, but when you need to develop a full stack app. You just dont have time to do everything from scratch.

These are decisions you have to make.

> date/time library

> leftpad

Yes, there is a difference between these.

There's also a difference between "we have a dependency on this versioned library that we have archived and deployed" and "we have a dependency on this library which we refer to dynamically at run-time".

But the second one gets you closer to the mythical perfection called "serverless" because it uses so many different servers you can't keep track of them all.

Leftpad isn't complex. It just adds spaces.

Datetime libraries are complex because they need to do things like deal with the fact that North Korea switched Timezones last year, that Fiji is changing their DST dates this year and other crap. We get about 3 to 10 releases of the TZ database every year and you'll probably want the updates as quickly as possible in your Datetime library to deal with timezoned data correctly, otherwise your Customer from Fiji will find that you aren't turning up for the meeting because you left an hour earlier believing the customer wasn't turning up at all. And then you have to deal with dates in the past where there might be possible changes to the entire calendar! Or different calendars such as the Japenese, Chinese or Jewish years.

I don't think it's valid to suggest that leftpad and datetime libraries are even on the same order of magnitude of engineering complexity.

Wouldn't advocate for total DIY. I recommend leveraging third-party libs and infra especially during experimentation or to buy increased development speed. Just calling out that those are long-term liabilities, and that when appropriate that tech debt should be paid down by writing code that you can control.

Build vs Buy has no universal answer.

Do you build? Or do you buy into the support level, the features, the bugs, the availability, the security, etc.

My rule of thumb is, write it yourself until it's painful, and spend a day looking for a good library to reduce the pain. If you can't find it after a day, or if you found one but it's taking longer than a day to configure it for your needs, try to write one yourself. This rule has not done me wrong yet. It's how I ended up moving away from Mobx and Redux in favor of RxJS and setState (just submitted a post about how to do this), and why I moved from Vue to React. But it is very subjective and subjectivity gets harder the more people you have on a team working on the same code.

I've actually come to prefer the opposite. I'd argue that the liability associated with third-party deps makes them debt. Debt is great for growth and experimentation. It works in a pinch especially if the experiment fails and you can just toss the dependency. So, today I'd rather buy, then build when I know I want to take on the pattern for better ops and long-term ownership.

This is the top comment, but I'm confused about how it relates to the linked article. The article doesn't really advocate outsourcing your software to third parties, just consolidating the infrastructure that you do own (sometimes in clever ways, like recursing your own PaaS) to make it as simple as possible.

From the article:

> Software that you write is software that you have to maintain. Forever. Don’t succumb to NIH when there’s a well supported public solution that fits just as well (or even almost as well).

While this idea has a lot of merit, it's not as black-and-white. (Most things in the world aren't, too.)

And frankly the "(or even almost as well)" is just wrong. I can't count how many times I've seen projects fail due to trying to shoehorn the problem into some existing solution because the NIH syndrome was so strong. Really if at first glance it looks like a perfect fit, it isn't, but you might get it to work. If right off you can see how it is not quite a fit, don't think you can make it work because you are most probably wrong. It will either fail outright or end up being way more work than if you had just solved it with custom code.

Reply on news.ycombinator.com