Simpson’s Paradox

Alice and Bob compete. Bob wins convincingly both times. But overall, Alice is better. How come?

This happens for real in medical trials and cases where you don’t have much control over the size of groups you test on:


AliceBob
Trial 1 Score8010
–Out Of /100 /10
––Percentage => 80%=> 100%
Trial 2 Score240
–Out Of /10 /100
––Percentage=> 20%=> 40%
Total Score8250
–Total Trials /110 /110
––Percentage=> 75%=> 45%

The points to notice:

• In each trial, they got different sized groups assigned to them. There can be good reasons for this. One procedure may be known (or thought) to be better for specific circumstances so it would unethical to assign procedure based on “we want to simplify our statistical analysis” rather than on best possible outcome. Or you may simply be combining statistics about things not in your control.

• Alice’s score for her largest group is better than Bob’s score for his largest group, but those ‘largest groups’ were in different trials so they only ever get compared in the overall figure.

More on wikipedia: https://en.wikipedia.org/wiki/Simpson%27s_paradox.

Choosing an Affordable Mechanical Keyboard

tl;dr: KeyChron are brilliant and cheaper than the alternatives.

My nephew was foolish enough to ask about the keyboard he spotted in a photo of my desktop so, armed with my Keychron K2, I explained what led me to it.

I got out kitchen scales and improvised some 2-10 gramme weights and carefully weighed the actuation force on my MacBook and on my Logitech K480. I found that the MacBook is approx 60grammes and that the K480—which I find too much hard work to type on—is about 70g. To me, the difference feels much more than that, but that’s what the scales told me. (And yes, the A-level physicists amongst you will know that by gramme I mean, milliNewton)

I deduced that any switch of 60g or below, I would be happy with.
I then noted that the Gateron Blue is allegedly noisy (fine if you don’t share a room with someone, anti-social if you do); and I examined the graphs of the actuation curves. I would have preferred the ‘clicky’ buckling spring feel of the Blue but I’ve used a noisy keyboard before and feel the noise can be a real downer. I definitely didn’t want the linear feel which the Red and Black have (allegedly gamers like it, but I don’t) so that left me with the Brown ‘Tactile’ which is in between.

I went for aluminium backlit because boo to plastic (don’t kid yourself though; I do not know whether the carbon footprint of producing the aluminium keyboard is any less than that of the plastic). Nightlife without backlighting is grim, it is must-have for me. My other must-haves are Mac keycaps, and either the “tenkeyless” keyset or the full 101 keys, because I hate not having page up/down and home/end on the main keyboard.

I agonised over K1 or K2 and went for K2 because K1 didn’t have the Brown switches. But … having become a closet Apple fanboi I am now disappointed that the K2 feels much higher off the desk that the Apple ultra-flat style and I may yet buy a K1 instead. Or a wrist rest.

I assure you however that the K2 is the best keyboard I’ve had for years. I had an IBM buckling spring keyboard for while in the 1990s, and a noisy Cherry for a while last year. The KeyChron has the same solid feel at the IBM had, but with the Brown switches is lighter and feels slightly less industrial. It is really nice, impressively priced, and I very much like it.

It will make you want to type long letters, or—should you happen to have WhatsApp Web on your computer—really really long messages to your nephew about how good your keyboard is. 🤷

Also 10% off! https://keychronwireless.refr.cc/chriscarroll

I did spend a while looking at other keyboards, mostly mechanical, but wasn’t willing to pay the enormous prices. KeyChron is a half or even a third of the price of other good mechanical keyboards. Seemed a no-brainer to me.

Deep Learning & Unintended Algorithm Bias

This was a 5 minute talk on deep learning for the very excellent @chesterdevs. Like others talking about deep learning, I took visuals and the face-learning example from the landmark 2012 paper, Quoc Le/Google/Andrew Ng paper, “Building High-level Features Using Large Scale Unsupervised Learning.”

Only afterwards did I notice that the subset of images which their system show as “most like a face” from their test set were 90% male and 90% white, as is the prototypical face that the machine outputs.

And so we have a neat demonstration of unintended algorithm bias: their input was 10 million randomly-chosen youtube videos; the output was white and male. I bet they didn’t expect that.

A salutary reminder that—as the hard-working statistician will tell you—“random selection” does not mean “unbiased”.

Conway’s Law & Distributed Working. Some Comments & Experience

The eye-opener in my personal experience of Conway’s law was this:

A company with an IT department on the 1st floor, and a marketing department on the 2nd floor, where the web servers were managed by the marketing department (really), and the back end by the IT department.

I was a developer in the marketing department. I could discuss and change web tier code in minutes. To get a change made to the back end would take me days of negotiation, explanation and release co-ordination.

Guess where I put most of my code?

Inevitably the architecture of the system became Webtier vs Backend. And inevitably, I put code on the webserver which, had we been organised differently, I would have put in a different place.

This is Conway’s law: That the communication structure – the low cost of working within my department vs the much higher cost of working across a department boundary – constrained my arrangement of code, and hence the structure of the system. The team “just downstairs” was just too far.  What was that gap made of? Even that small physical gap raised the cost of communication; but also the gaps & differences in priorities, release schedules, code ownership, and—perhaps most of all—personal acquaintance; I just didn’t know the people, or know who to ask.

Conway’s Law vs Distributed Working

Mark Seemann has recently argued that successful, globally distributed, OSS projects demonstrate that co-location isn’t all it’s claimed to be. Which set me thinking about communication in OSS projects.

In my example above, I had no ownership (for instance, no commit rights) to back end code and I didn’t know, and hence didn’t communicate with, the people who did. The tools of OSS—a shared visible repository, the ability to ‘see’ who is working on what, public visibility of discussion threads, being able to get in touch, to to raise pull requests—all serve to reduce the cost of communication.

In other words, the technology helps to re-create, at a distance, the benefits enjoyed by co-located workers.

When thinking of communication & co-location, I naturally think of talking. But @ploeh‘s comments have prodded me into thinking that code ownership is just as big a deal as talking. It’s just something that we take for granted in a co-located team. I mean, if your co-located team didn’t have access to each other’s code, what would be the point of co-locating?

Another big deal with co-location is “tacit” knowledge, facilitated by, as Alistair Cockburn put it, osmotic communication. When two of my colleagues discuss something, I can overhear it and be aware of what’s going on without having to be explicitly invited. What’s more, I can quickly filter out what isn’t relevant to me, or I can spontaneously join conversations & decisions that do concern me. Without even trying, everyone is involved when they need to be in a way that someone working in a separate room–even one that’s right next door–can’t achieve.

But a distributed project can achieve this too. By forcing most communication through shared public channels—mailing lists, chatrooms, pull request conversations—a distributed team can achieve better osmotic communication than a team which has two adjacent rooms in a building.

The cost, I guess, is that typing & reading is more expensive (in time) than talking & listening. Then again, the time-cost of talking can be quite high too (though not nearly as a high as the cost of failing to communicate).

I still suspect that twenty people in a room can work faster than twenty people across the globe. But the communication pathways of a distributed team can be less constrained than those same people in one building but separated even by a flimsy partition wall.

References