[TZubiri]

You might argue that it is never worth it to roll anything on your own (which is already an extreme proposition), but to argue that it has no benefits (other than cost?), I think it's either bad reading comprehension or overzeal to jump into the keyboard and type dogma that you should never roll your own and that you should download 1000 dependencies and a dependency manager to manage all those version conflicts.

[crazygringo]

It's not being overzealous.

If you're a startup and you need something and it already exists, why would you write your own instead? Even if it's clunky, it saves you time.

And for startups, speed and runway is everything. Rolling your own is not a luxury you have.

Especially when you consider how much of the startup experience is changing requirements, pivoting, throwing out code, etc.

And I've never seen 1,000 dependencies in my life. Sure maybe you have 50. That's entirely manageable. Think how much time you'd lose writing and testing all that stuff yourself...

[TheNewsIsHere]

Although my company isn’t recognizable as a startup given its age, I can say confidently that the typical advice to avoid rolling your own is not a given.

Many new founders and businesses fail to consider the supporting systems they need outside the code their product or service is comprised of. This can cause a lot of unnecessary re-engineering later.

As we built our company we had to make a number of decisions about whether to build our own or go with a third party. At various points we did both, and for us the DIY approach has continuously been the better option over time. That doesn’t mean we write our own code for everything but it does mean we sometimes do, and it means we don’t just go with whatever is the most convenient. An increasing amount of our IT estate is self-hosted applications rather than SaaS apps, for example.

By way of example, we had started off with a really popular accounting package that everyone uses for everything but which isn’t very customizable (and which doesn’t provide backups). That became untenable after only a few years because we our service demanded a more bespoke approach to linking service and financial data. We knew that going in but we took the same “it’ll do for now” attitude. That ended up creating more pain later. We moved to an ERP platform that we can host (and backup!) and haven’t looked back.

We almost did the same with our infrastructure management. We had evaluated and used a number of proprietary products and services from AWS, Hashicorp, CI/CD, and RMM vendors.

Ultimately we created our own stack on the back of FOSS and custom code which took a lot longer to mature but which has proven to be much better for our needs.

[TZubiri]

There's pros and cons to everything.

One advantage of rolling your own:

-minimalism: no code designed for othere -security: not necessarily more secure, but a different risk profile. You are safe from a lot of spearphishing vulns like log4j, but may be open to custom attacks, I think this is an advantage but ymmv. - system knowledge: you can answer questions about your system, to clients and regulators.

- system flexibility: you understand your system you can modify it as needed. Which is not true if you import 1000 dependencies.

[TZubiri]

> I've never seen 1,000 dependencies in my life. Sure maybe you have 50. That's entirely manageable.

50 immediate dependencies add up to much more than 1000 total dependencies.

If you install a linux OS you are already at 1k. Check your packages

[crazygringo]

So... you're suggesting startups should roll their own operating system before building their product?

Because I don't see any other way of interpreting your comment.

[TheNewsIsHere]

That was surely an example to illustrate how easily you can end up with 1,000 dependencies. Actual numbers vary of course, but the point that I got was about how dependencies spiral.

They do. Especially for web based applications built on frameworks and libraries that make it easy to pull in dependencies through package management. I used to work for a company that wrote a stack in Go with a TypeScript front end. When you compiled the whole thing there were easily 900 dependencies resolved, and 885 of those weren’t written internally.

An OS and its package manager are no different, but are a more accessible and less specific example to cite.

[TZubiri]

You should work in reading comprehension, try reading what's actually there instead of trying to find a hidden meaning