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.
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.
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
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.
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.
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
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.
>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.
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.
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.