>At some point it would be easier to rewrite code from scratch with less complexity and overhead.
I'd agree, and probably wouldn't have commented.
But I think being all of these things:
>consistent, predictable, cheap, generic, and ubiquitous.
Means you have a damn good product. No one is claiming you can't get something better, but come on, I'd love to have software that's consistent, predictable, cheap, generic, and ubiquitous.
If those words describe a popular library, and you decide instead to build your own thing in-house... you better have a really REALLY good reason for doing it.
> Means you have a damn good product. No one is claiming you can't get something better, but come on, I'd love to have software that's consistent, predictable, cheap, generic, and ubiquitous.
Note that I never said "consistently good" or "predictably reliable". There are a lot of things in the world that are known to be low-quality, single-use crap that are still everywhere.
> If it hadn't been for the last sentence:[...]
I think it depends on their idea of where "at some point" lies.
I'd settle for consistent, predictable, and cheap. Generic doesn't matter if it solves my specific problem and ubiquity is a social problem. Enterprise pays a lot for bespoke solutions as well.
A very good reason to write your own software is if the problem is novel enough to warrant it. I'm not advocating that there should be n+1 JSON serialization libraries.
>At some point it would be easier to rewrite code from scratch with less complexity and overhead.
I'd agree, and probably wouldn't have commented.
But I think being all of these things:
>consistent, predictable, cheap, generic, and ubiquitous.
Means you have a damn good product. No one is claiming you can't get something better, but come on, I'd love to have software that's consistent, predictable, cheap, generic, and ubiquitous.
If those words describe a popular library, and you decide instead to build your own thing in-house... you better have a really REALLY good reason for doing it.