With enough customers, dealing with everyone who can't use your slapped-together form will be more expensive than doing it right.
The way you write shows some deep assumptions: that this is a case of "slapped-together" vs. "great" software, for example. And those assumptions are, I'd assert, counterproductive to the discussion at hand.
The comment I was replying to actually was a real-world example of what you're missing, namely that this is a trade-off. Every time you support another 0.0001% of corner cases, you're increasing the surface area of potential failures for other cases. And since the other cases are far more common, they're going to bite you more often.
Supporting the most common cases, to a 99.9% or so level, directly and then having an escape hatch for the rest is not "slapped together" -- it's deliberate design which takes the problem and the cost/benefit of different solutions into account. It's also, from that perspective, almost certainly the correct design.
And yet it gets blasted repeatedly in articles like the OP here, which assume that the only possible reason for such design is ignorance/incompetence on the part of the developer. That simply is not true, and you should stop implicitly buying into that (it's another assumption that's hidden in the way you write).
The way you write shows some deep assumptions: that this is a case of "slapped-together" vs. "great" software, for example. And those assumptions are, I'd assert, counterproductive to the discussion at hand.
The comment I was replying to actually was a real-world example of what you're missing, namely that this is a trade-off. Every time you support another 0.0001% of corner cases, you're increasing the surface area of potential failures for other cases. And since the other cases are far more common, they're going to bite you more often.
Supporting the most common cases, to a 99.9% or so level, directly and then having an escape hatch for the rest is not "slapped together" -- it's deliberate design which takes the problem and the cost/benefit of different solutions into account. It's also, from that perspective, almost certainly the correct design.
And yet it gets blasted repeatedly in articles like the OP here, which assume that the only possible reason for such design is ignorance/incompetence on the part of the developer. That simply is not true, and you should stop implicitly buying into that (it's another assumption that's hidden in the way you write).