March 2012 – rc3.org

Month: March 2012 (page 1 of 2)

Documenting the harm caused by airport security post-9/11

Today Bruce Schneier writes up the actual harms caused by airport security policies imposed after 9/11. It’s easy to decry these policies for their stupidity and costs, but describing the ways they cause actual harm is more work. This piece is a must read — here’s a snippet:

This loss of trust—in both airport security and counterterrorism policies in general—is the first harm. Trust is fundamental to society. There is an enormous amount written about this; high-trust societies are simply happier and more prosperous than low-trust societies. Trust is essential for both free markets and democracy. This is why open-government laws are so important; trust requires government transparency. The secret policies implemented by airport security harm society because of their very secrecy.

Cleaning up after DNS Changer malware

March 28, 2012 / Rafe / 0 Comments

Paul Vixie (the guy who wrote the BIND DNS server) talks about his efforts to clean up the effects of the DNS Changer malware, which changes the DNS settings on the host computer (and sometimes the routers they use). DNS Changer was, in essence, a black hat advertising network. If you paid them, they would alter the malware victims’ DNS searches to redirect them to sites that promoted your products.

After the DNS Changer network was taken down, Vixie’s job was to come in and stand up replacement DNS servers to take the place of the bogus ones, so that victims of the malware didn’t suddenly lose the ability to perform DNS lookups. In the meantime, the working group is trying to remove the malware from hundreds of thousands of devices before the new DNS servers are taken down by court order on June 9.

Interesting look at a tough problem.

Understanding offensive football in two paragraphs

March 25, 2012 / Rafe / 0 Comments

Let’s say you are a casual football fan who doesn’t really understand how football strategy works. Chris Brown explains the purpose of every offensive scheme in two paragraphs:

With 11 players to each side, every play — but particularly run plays — often comes down to how the offense does or does not account for one or two particular defenders. In the modern NFL, if all of an offense’s players block their counterparts on a running play, the defense will have two defenders unaccounted for: The counterpart for the running back carrying the ball and the counterpart for the quarterback, who most likely has handed the ball off. Good quarterbacks like Peyton Manning seek to control their counterpart by faking a play-action pass, so that a deep safety must stand in the middle of the field.

But the ballcarrier still has a counterpart. NFL offenses work extremely hard to dictate who that guy will be — with motion, different blocking schemes, and even using wide receivers to block interior defenders — but at some point the math is the math. Until the quarterback is a threat, the math will always work against the offense. But spread coaches, without subjecting their quarterbacks to undue brutality, have learned to change the calculus.

That’s from an article on how the New York Jets will use Tim Tebow, but if you understand those two paragraphs, you will understand more about football than most people who watch it all day every Sunday.

Distributed systems do not provide free reliability

March 19, 2012 / Rafe / 0 Comments

Distributed database creator and LinkedIn engineer Jay Kreps pokes a hole in the widespread myth that systems that scale horizontally are inherently reliable. This is an important post, because intuitively it seems like a system that scales horizontally and makes provisions for fault tolerance should be reliable. Indeed, that’s the value proposition for many people. Rather than having to be smart enough to provision big servers intelligently and figure out how to make them fault tolerant, you can just throw commodity hardware at the problem and be ready to swap out systems when you encounter the occasional hardware failure.

If you enjoy that article, move on to Daniel Abadi’s post on Replication and the latency-consistency tradeoff. It’s not about system failure but about the performance characteristics of distributed systems. This is the sort of real-world issue that is glossed over when you talk to people about distributed systems a lot of the time.

The hype about the new distributed database systems is that they make life easy. The truth is that they’re incredibly complex, but they make it possible for small companies to achieve things that were out of reach for all but the largest companies until very recently. I’m just starting to wrestle with some of this stuff and you can expect more posts about this topic.

The Mike Daisey scandal in a nutshell

March 17, 2012 / Rafe / 2 Comments

I’m going to let you skip listening to the Retraction episode of This American Life. Here are two short snippets from the transcript. First, This American Life made it clear what they expected from Daisey. This bit is from an email that This American Life producer Brian Reed sent to Mike Daisey before the original episode excerpting Mike Daisey’s show aired:

Being that news stations are obviously a different kind of form than the theater we wanted to make sure that this thing is totally, utterly unassailable by anyone who might hear it.

And why did Mike Daisey lie to everyone? Here’s why:

I think I was terrified that if I untied these things, that the work, that I know is really good, and tells a story, that does these really great things for making people care, that it would come apart in a way where, where it would ruin everything.

The rest is just details.

Mike Daisey, Sandra Fluke, and the importance of credibility

March 16, 2012 / Rafe / 4 Comments

The big news in my little corner of the world today is This American Life’s retraction of the show they did that included a long excerpt of Mike Daisey’s one man show, The Agony and Ecstasy of Steve Jobs. In the show, Daisey contrasts the Apple products that are known and loved by both he and most of his audience with the labor conditions under which they are produced in China. Much of the emotional power of the story derives from the fact that Daisey travelled to China himself to meet workers in the factories. In his show, he alternates between telling the history of Apple and his own first-hand accounts of meetings with the workers.

Today we learn that This American Life has issued a retraction because they fact-checked Daisey’s story and found that it was not 100% true. The translator Daisey hired features prominently in his stories, so This American Life asked to contact her to verify his story. He gave them a fake name for the translator and claimed he could not get in touch with her. They wound up locating her themselves and found that she disputed significant portions of Daisey’s tale.

Daisey claims to have met a 13 year old worker in the Shenzhen factory. He did not. That said, Chinese factories do employ underage workers to build Apple products. Daisey claims to have met workers who suffered permanent damage because they are forced to use n-hexane to clean the screens of devices. That chemical is not used in the factories he visited. Even so, that chemical is used in other factories that assemble Apple products. He claims to have met a man whose hands were twisted due to repetitive stress injury caused by assembling iPads who had never actually used an iPad. According to his translator, that did not occur. Can there be any doubt that nearly all of the factory workers in China never get to use the products they assemble?

The problem for Daisey in terms of credibility is that he tells these stories in the first person. He went to China to find out what was really going on, and this is what he found. Much of the power of his story derives from this personal connection — he is telling you first hand what he heard. You can find the same facts using Google, just like I, and presumably he, did. The personal narrative is the hook. People who find stuff on Google and tell you about it have blogs, not critically acclaimed stage shows. Unless the “Mike Daisey” in the show is a fictional character, the audience expects that his first-hand stories are true. When we learn that they are not, the air leaves the balloon.

People tend to pay more attention to stories when they are personal. Let’s look at the example of Sandra Fluke. Her Congressional testimony made a couple of essentially non-controversial points — many women use contraception for reasons other than birth control, and that it can be difficult to afford if your insurance doesn’t pay for it. You can find any number of politicians, reporters, public health experts, doctors, and random people on the street who will confirm them.

When a story pricks at our conscience, our brains tend to look for a way out and the easiest way out is to dismiss the story because we don’t trust the person who told it. So it’s easier for Rush Limbaugh to attack Sandra Fluke than to attack her testimony. His goal was to make people feel that she could be safely ignored, and he went about it in just about the most disgusting way possible.

Because the power of stories is so tightly coupled with the credibility of the teller, it’s especially important to avoid self-inflicted wounds. Here’s what Daisey says:

I stand by my work. My show is a theatrical piece whose goal is to create a human connection between our gorgeous devices and the brutal circumstances from which they emerge. It uses a combination of fact, memoir, and dramatic license to tell its story, and I believe it does so with integrity. Certainly, the comprehensive investigations undertaken by The New York Times and a number of labor rights groups to document conditions in electronics manufacturing would seem to bear this out.

I’m sympathetic to his argument. All the stuff he talks about really did happen, if not to people he talked to. The problem, though, is that the impact of his story hinges upon his credibility as the teller. He must have known that when he tried to prevent This American Life from getting in touch with his translator.

Fortunately for the workers in China who deserve to work under better conditions, their story has taken on a life far beyond The Agony and Ecstasy of Steve Jobs. Finding out that Mike Daisey was more interested in telling a powerful story than telling a true story is not enough to let Apple or its customers off the hook. He should be thankful for that.

For reasons of thoroughness, here’s Rob Schmitz’ report on his investigation into Daisey’s show. I also note with sadness that Cathy the translator does not seem to wear overlarge glasses that always need to be pushed up.

Update: This American Life digs deeper this week.

Let’s talk about interviewing programmers

March 16, 2012 / Rafe / 6 Comments

Lately, I’ve been interviewing a lot of developers. Not phone screens, but in house interviews that we use to decide whether to hire someone who’s passed the first round. In addition to trying to figure out who the good candidates are, I’m also trying to get better at interviewing.

If you’re getting started with interviewing programmers, there are a couple of must-read articles. The first is Steve Yegge’s article, The Five Essential Phone-Screen Questions. This article is incredibly well-known and I assume everyone has already read it.

The second is Joel Spolsky’s The Guerrilla Guide to Interviewing. He recommends asking an “impossible” question (as anyone who worked at Microsoft probably must). I never ask these kinds of questions. Other than that, I think he’s got it right. You want to know if they can code, if they can design something, and how well they think.

One thing that stands out to me, though, is that none of his questions tell you what kind of team member the candidate will be. This is a major deficiency as far as I’m concerned.

Basically, at the end of an interview, the one question I want answered is, “Will it suck to work with this person?” As Joel points out, it’s important to hire smart people who get things done. It’s also important to hire people who won’t make the people around them miserable. I want to hire people who are flexible enough to adapt to the company culture and open-minded enough to recognize other people’s good ideas. I also want people who are patient enough to bring other people up to speed on their work.

There are a few questions that I’ve settled into asking almost everyone. I don’t worry about people finding me on Google and knowing in advance that I’ll ask these questions because I’d just as soon they come in already knowing the answers.

I almost always lead off with, “Tell me your timeline of programming languages.” I want to know how long they’ve been programming and how many languages and platforms they’ve used in their career. All things considered, I generally prefer programmers who’ve worked extensively with multiple languages. This question is also an easy way to find out which people started programming early in life.

Next, I usually ask them about some experience from their résumé, I’ll pick a project and drill down to find out what the project was, what role they played, and how well they can explain what they worked on.

I then ask them some questions about teamwork. I’ll ask them to tell me something they learned from another developer. Many people talk not about technical concepts but about habits of work, and either sort of answer is fine. If they can’t tell me something that they’ve learned from someone else, that’s a big red flag.

I ask them to tell me something that they’ve changed their mind about when it comes to software development. If you can’t remember changing your mind about anything, you may be too stubborn to work well on a team. It turns out that lots of people have changed their mind about the ternary operator. It’s polarizing.

I will generally ask candidates how they test their own code, to find out what kinds of automated testing they use (or don’t use).

The last question I have started asking almost everyone is to tell me something that they would rewrite if they were given time. It’s a good way to get someone to talk about something they feel strongly about and also to find out what they see as good and bad code. It’s also telling if they want to rewrite something someone else wrote rather than something they wrote.

I’ll also ask a few questions about why they’re looking for a job and what interested them about the company just to get a sense of how interested they are in the position. And of course I ask them if they have any questions for me.

There are three other areas that I think are important to hit, and this is the area where I’m still working on my technique. Those are coding, design, and problem solving. The trick is to fit all of it into the short window that I usually have for the interview. At worst, if multiple people are interviewing the candidate, you should make sure that at least one person will be hitting each of these three areas.

The ideal programming question as far as I’m concerned should be simple enough to solve in a couple of minutes, and be deep enough to have multiple solutions. The best questions have at least a brute force solution and an elegant solution. You can gauge the candidates on which they come up with. I refuse to ask the famous Fibonacci sequence question. There are better alternatives. That said, if you are interviewing for programming jobs, you should be able to write a program that prints the Fibonacci sequence using a loop or using recursion. Someone will ask you to do so.

Design questions are discussed comprehensively in Steve Yegge’s article, which I linked to previously. The goal is to determine whether the candidate understands object-oriented design. The model should be simple enough that you can get past the classes and get into talking about the methods on those classes.

Finally, I think it’s good to ask a question that tests the candidate’s problem solving skills. They should be able to list possible solutions and discuss the pros and cons of each of them. I’m going to write a separate post about this type of question later.

Yahoo brings the patent war to the Web

March 13, 2012 / Rafe / 4 Comments

Yahoo has filed a lawsuit against Facebook for violating ten of its patents. You will not be surprised to learn that the patents are for obvious implementations of features that have all been used on literally hundreds if not thousands of Web sites. Facebook is about to generate a huge amount of capital through its IPO and Yahoo has its eye on the loot.

It’s hard to beat Fred Wilson’s direct response, but my personal favorite is Andy Baio’s. His perspective as a startup founder whose company was acquired by Yahoo is particularly interesting.

The question people who are concerned about the ongoing damage that patent litigation is inflicting on the technology industry need to be asking is how to make this a political issue that lots of people care about. Everyone I know who’s a technology insider sees this as a hugely important issue, but most people on the outside are hardly aware of it. If you need a refresher on this issue, there’s no better place to start than This American Life episode 441, When Patents Attack!

Jacob Goldstein, who did the This American Life story on patents, has a piece up about the Yahoo lawsuit.

The concise case for code reviews

March 12, 2012 / Rafe / 2 Comments

Google engineer and former Harvard professor Matt Welsh does a great job of making the case for code reviews. I have never worked in a shop where code reviews were mandatory for every change, or even commonly held, but I’ve always wanted to for all of the reasons Matt Welsh explains. There are a lot of excuses for not doing code reviews, but I can’t think of any more efficient way to encourage developers to learn from one another and to develop a cohesive coding style that spans an entire team.

Expertise makes the impossible seem easy

March 9, 2012 / Rafe / 0 Comments

What is impossible for novices is easy for experts. Take a look at what Damir Sagolj refers to as the “easiest big picture he shot for a long time” and then check out more of his work.

rc3.org

Strong opinions, weakly held