[I can't respond to your comment directly. This is a bit off-topic, but I think it's interesting!! Here goes.]
> It is true that "not all men are the same" (and "not all women are the same"), but splitting into "trans male" and "trans female" is probably more accurate than lumping all "trans people" into one category.
> After all, it would be silly to have only 2 chategories "trans" and "cis" (trans:cis :: gay:straight).
My original post was in jest—in fact, it was inspired by some holy-crap-I-can't-believe-it's-real database schema I've had to work with. Someone made an effort to hyper-normalize things and saddled us with a disaster: Every query required seven or eight slow joins, and there was duplicate data sprinkled everywhere (in my example, the same patient could inadvertently have records in both the Male and Female tables). The "architect" quit a few weeks after it went to production.
Anyway, I consider (biological) "sex" to be a sliding scale: one end being female, the other end being male, and the middle being intersex. I consider (social) "gender" to be where one self-identifies on that scale. Others might disagree, but I think this is a useful distinction.
Upon reflection, it's obvious that my schema isn't even remotely helpful! My inclusion of the "Transgendered" table implied that the three tables were genders, not sexes. Gender, being a self-identified trait, has nothing to do with whether one can get pregnant.
So if we wanted to hyper-normalize our schema and indicate that only certain patients can get pregnant, we should clearly have a "Uterus" table. In fact, it would probably be wise to have tables for every body part, and inner-join on all of them whenever we need to grab a patient's information. Or we could use check constraints... but our schema diagrams would be much less impressive.
If you feel resentful toward your coworkers or are planning on quitting your job soon:
You could have Male, Female, and Transgendered tables, each of which point back to the Patient table. Only the Female table (and perhaps the Transgendered table) would have an isPregnant column.
I'd love to have a delightful product, and I'd love for it to be given positive press to over a hundred thousand people! But like Android back in 2008, I don't think I'd get there without scrappily alleviating a pain point, getting my foot in proverbial door, and just shipping. Had Google waited and waited, they might be where Microsoft is now with WP7—an awesome product with really nice details that no one uses.
Granted, it's easier to switch cat feeders than phone OSes, but I think the point still stands—if you alleviate a pain point[1], you can tweak your product to make it delightful later.
Thanks for keeping up with your blog, and congrats on your three little humans! Do they make automatic feeders for those yet? Perhaps if you clean out your old cat feeders really well...
[1]: If you enter an existing market with nothing to differentiate your product (including price), then yes—you're probably going to fail.
> Your software, your product, is nothing more than a collection of tiny details. If you don't obsess over all those details, if you think it's OK to concentrate on the "important" parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis – you're not creating great software. Someone else is.
I think the true moral of his story contradicts his conclusion.
He and his wife had a problem: They didn't like manually feeding their cats. So they bought a couple of automatic cat feeders and enjoyed owning them—despite several small, annoying flaws. In fact, he and his wife dutifully employed those feeders for five years until he noticed (and purchased) the company's newer, improved version!
I liked the essay, but I suppose Jeff and I disagree on what the story teaches us.
This story is about a company that identified a pain point (manually feeding cats is annoying) and created a product that alleviated the pain (an automatic cat feeder) despite several flaws (a bad color, an annoying button guard, and a difficult to clean food bowl, to name a few). Over time, the company resolved those flaws, but they didn't wait until all of the flaws were resolved before initially shipping their product. Instead, they shipped a useful, albeit imperfect product, and earned themselves at least two repeat customers.
> It is true that "not all men are the same" (and "not all women are the same"), but splitting into "trans male" and "trans female" is probably more accurate than lumping all "trans people" into one category.
> After all, it would be silly to have only 2 chategories "trans" and "cis" (trans:cis :: gay:straight).
My original post was in jest—in fact, it was inspired by some holy-crap-I-can't-believe-it's-real database schema I've had to work with. Someone made an effort to hyper-normalize things and saddled us with a disaster: Every query required seven or eight slow joins, and there was duplicate data sprinkled everywhere (in my example, the same patient could inadvertently have records in both the Male and Female tables). The "architect" quit a few weeks after it went to production.
Anyway, I consider (biological) "sex" to be a sliding scale: one end being female, the other end being male, and the middle being intersex. I consider (social) "gender" to be where one self-identifies on that scale. Others might disagree, but I think this is a useful distinction.
Upon reflection, it's obvious that my schema isn't even remotely helpful! My inclusion of the "Transgendered" table implied that the three tables were genders, not sexes. Gender, being a self-identified trait, has nothing to do with whether one can get pregnant.
So if we wanted to hyper-normalize our schema and indicate that only certain patients can get pregnant, we should clearly have a "Uterus" table. In fact, it would probably be wise to have tables for every body part, and inner-join on all of them whenever we need to grab a patient's information. Or we could use check constraints... but our schema diagrams would be much less impressive.