I’ve found little difference in long-term maintenance time between rolling my own and using third-party services/libraries in practice. Services change and go away. Libraries change and add complexity to the build and project. At least when it’s your code, you’re in control.

One of the greatest fallacies in modern software development is how much everyone seems to completely ignore the time, complexity, risks, and long-term maintenance costs of adding so much third-party code and infrastructure to everything.

The funny thing is that in many BigCo environments dealing with an internal team in another location that provides some software thing is similar in complexity to dealing with an outside company.

This just isn't true. I can write a program that will produce H.265 encoded video and upload it securely, I don't need to boil the ocean by writing my own video encoder or becoming an expert in cryptography. We're all standing on the shoulders of giants.

100% agree

I feel there is a steep trade off here. If the current state of the art solutions to the problem domain are good enough for your use case for the long haul, or you’re funded well enough and the problem domain is important enough for sustained R&D on the codebase then sure.

But we are collectively exploring these problem domains. Going it yourself means your okay with a customized snapshot of the industry’s state of the art OR you’re able to out innovate the community in this problem domain.

But I’ve seen this late stage over and over again, especially in services other teams rely on. The custom implementation becomes a bottleneck for the company’s innovation, it’s so custom and well integrated there isn’t an open alternative anymore, 1/2

and the state of the art has clearly progressed far beyond what the custom solution provides. It becomes a sunk cost cost center and it’s _really_ difficult and expensive to get out of this state.

It's a common selling point from companies trying to sell you an off the shelf replacement to your fully custom solution. In some cases it makes sense (nobody would build their own zoom), but in some other cases the state of the art will never serve your need better than you.

Proprietary software is proprietary software regardless of whether you build it yourself or but it. Buying software from a company trying to compete against open source needs to go through the same value prop evaluation.

The company trying to sell you the off the shelf thing is making the same assertion that your internal team is making: we can out compete the commons for your use case.

In some cases they can (photoshop, alerting, and video conferencing) but in many cases (especially infrastructure) trying to out innovate the community is a fool’s errand.

I just recently removed the last third party dependency from my app and I love it.

Really? Where do you draw the line? Avoid crypto libs (OpenSSL & etc)? Avoid network libs (HTTP, TCP, UDP, IP & etc)? Avoid graphics libs (OpenGL, Vulcan, Metal, DirectX & etc)? Avoid operating system libs (Linux, macOS, Windows & etc)? Seems improbable.

There is likely a “sweet spot” but not relying on shared code, ever, doesn’t seem like it.

Perhaps I am just old, but dependencies are the scourge of software development.

People never seem to account for the amount of time required to keep up with API changes in the libraries you decide to adopt, too. It's not like using a library means you suddenly have no maintenance costs.

Oh, and, adding libraries to your project ALSO means that you're now adding all the undiscovered vulnerabilities in those libraries and their dependencies, too.

Never underestimate people’s ability to stick their fingers in their ears, and never update anything

And it's the least fun sort of work tbh...

Or security risks. The number of times we’ve had high priority fixes across a whole load of business apps internally due to issues in struts or spring! We’ve probably lost literal years of time dealing with mandatory updates

jinx:

Case in point: Finding some four-year-old projects that are available on GitHub and haven’t been touched since. Trying to get them to run will probably drive you insane if they have any dependencies, even if they’re just small Python utilities.

It feels a bit like it is part of the lifecycle of a developer. At first you write it all from scratch because you don’t know there’s a library, then you find libraries and pull in libraries for everything. And eventually you say f*** it, I’ll just do it myself.

I think especially when integrating with 3rd party APIs, and usually you just need to call 2-3 endpoints, you’re not making a whole client for the 3rd party service to use a full blown SDK!

Totally. I scream (apparently into the void) at all the ridiculous cocoa pods my company uses. Drives me insane how we cannot upgrade quickly. What time did we actually save again?

>At least when it’s your code, you’re in control. This form of control is a "fiction" , a story we tell ourselves in one's mind. Then again those other things are just as much a fiction so we are arguing over which is more "phony" of a story.

What exactly do you mean by “control” here? You can always fork a project at the point where you need that control. Are you referring more to the creeping hidden change + complexity in a library or is control really a better understanding of the implementation?

I’ve found this not to be the case when working on a team. This might be true of a one man operation, but if someone on the team rolls their own — and then leaves — I find the upkeep and maintenance to often outstrip the initial convenience. Not always, but often.

I don't disagree with this, exactly, but it's a weird thing, too. There's something in here about the limits in building anything (buildings, cars, societies, software) at the individual level and complexity. Roll your own only gets you so far.

Maybe we're not building software complex enough that working in teams and integrating the work of others is required. Or maybe we're just really, really bad at it.

If you’re a fan of libraries, you’ll hit that problem every year, when Apple releases a new Xcode and you can’t adopt the new OS features because none of your third-party code compiles

not gonna lie, this sounds more like an Xcode problem than a "libraries" problem 🤷🏼‍♂️ Of course, that's the reality you have, so you've got to work with it.

Have you ever been forced to update a library that worked just fine for you? 🙄

If only executives understood this. The Problem is third party code has a sells department while your own code has a bunch of software engineers. Who’s going to win this battle when it comes to selling the ceo and what direction to take.

Unless it’s a stupid amount of work, most clients I do work for ( python dev ) would rather I write a lib they own, than use a third party that might go away, or be changed for the worse.....

Yeah I don't see the problem with rolling your own services to support your apps in most cases. Seems more than prudent, also future proof. Most apps are relatively simple. It's not like you need to write the Unreal Engine from scratch.

I couldn’t agree more. I am disappointed by the CocoaPods culture that pervades iOS development now.

It’s so funny I listened to your rant about this on ATP last night and this morning heard about one dependency breaking create react app