Edge Case Poisoning (2020)
buttondown.email
Edge Case Poisoning (2020)
1–10 of 49 posts
Re: Edge Case Poisoning (2020)
#2This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily.
Re: Edge Case Poisoning (2020)
#3Oh man, I just had a flashback to the 90s and trying to create a recipe database and all this stuff made me give up. Which I think was probably a better choice than so many of the programs that will turn recipes into shopping lists made.
Re: Edge Case Poisoning (2020)
#4This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily.
If there are bugs in software but no one ever runs it, does it really have bugs?
- George Berkley (apocryphal)
Re: Edge Case Poisoning (2020)
#5Data scientists have the right approach here. Crop the outliers, use the mode for sparse data, make an embedding of categorical variables. In short, just pretend like the data is normalized because that makes for a more accurate model of reality in practice.
Re: Edge Case Poisoning (2020)
#6Data scientists have the right approach here. Crop the outliers, use the mode for sparse data, make an embedding of categorical variables. In short, just pretend like the data is normalized because that makes for a more accurate model of reality in practice.
I'm not sure that translates to situations where you aren't aggregating data
Re: Edge Case Poisoning (2020)
#7Data scientists have the right approach here. Crop the outliers, use the mode for sparse data, make an embedding of categorical variables. In short, just pretend like the data is normalized because that makes for a more accurate model of reality in practice.
Good data science only "psuedo crops" for scale.
Eg: Sat imagery is scan lines full of instrument return values.
The first normalisation is to use 99.9% of the returned value range to setup a colour lookup table.
.1% of the return values could be :
* lens flare
* instrument error
* actual valid but extreme data values.
Depending on the problem domain, after removing (actual) error and bogus values (where possible) you might actually be using the 99.9% of the data to "train" for normal expected background stuff ... and you're really looking for the edge case that is Gold | Uranium | a Hidden tank, etc.
Re: Edge Case Poisoning (2020)
#8This is too real. It happens very frequently even with relatively structured data.
Re: Edge Case Poisoning (2020)
#9When doing this for scientific protocols I found that you basically have to give up any hope of specializing types of things. The domain ontology for documenting processes, be they making cupcakes or electron micrographs, has to be matched to the domain in question.
Some might say that for processes this means everything must be extremely abstract in order to avoid edge cases like those encountered by the author. However, I would argue that from the perspective of someone executing a recipe they do not care at all about whether something is edible or food or not, they only care how much they need of something (count is a unit(less) of measure). Thus, the ontology proposed by the author is not matched to the domain.
The first mistake was trying to make a distinction between food and non-food. What if I used paper cupcake cups? They may not technically be food, but I have certainly eaten parts of them before by accident. Other parts of the system might care about food/non-food, but these parts are constrained by a separate and likely orthogonal set of use cases.
I don't usually need to know the chemical formula for sodium bicarbonate to order it from a vendor, but if I need to automatically calculate stoichiometry for reactions so that I can automatically order the correct amount then I might. Those two parts of the system can and should be completely orthogonal to each other and thus fully decoupled.
Therefore, I would suggest that encountering something that looks like "edge case poisoning" is a sign that you have not properly factored the system.
Re: Edge Case Poisoning (2020)
#10What a useful idea to coin a term for! I've seen a huge amount of sweat go into edge case functionality over the years, especially in large systems. I wonder exactly how much you could get away with not doing, if you had good insight into user behavior and applied this philosophy liberally and brutally.
But I'm also a bit skeptical about how far you can push the idea beyond the kinds of design tradeoffs people already make. It's often hard to be certain about which edge cases will prove to be important or valuable in the future, and when you cut this sort of corner, changing your mind later can sometimes be very, very expensive (e.g.: I've experienced the pure agony that comes with migrating away from ancient mainframes, which handled every single edge case in plaintext). Not to mention that in large systems, every tiny edge case ends up being useful to a huge number of people anyway.
Perhaps this term is helpful in the same way that "technical debt" is: it encodes a framing that the desire for hygiene or completeness should be balanced thoughtfully in terms of user benefit and added complexity.