Why was BritRuby cancelled?

Permalink • Read Later

Besides the pseudo-official line that sponsors got nervous about a controversy about diversity on Twitter, why was BritRuby cancelled?

In fact, the organisers had announced two sponsors before they called it quits, On The Beach and globaldev. Both of them have disclaimed concern about the controversy:

No #britruby - incredibly sad. As a sponsor I know the attacks are ill-founded. All that’s happened is a great conf is dead. No winners.

— Jonathan Smith, CTO of On The Beach, Twitter.

The cancellation of BritRuby is a shame and we want to state categorically that Globaldev backed BritRuby 100% regardless of the twitter controversy.

— Steve Buckley, globaldev blog, “Our Response to BritRuby’s Cancellation”

So what’s the real story? Did they hope for more sponsors, but were turned down because of the controversy? Surely a little re-assurance that no discrimination was intended in the selection would suffice? I’m sure plenty of potential sponsors wouldn’t have been phased by a little ruckus on Twitter. Indeed, the Golden Gate Ruby Conference — incidentally, organised by one of the folks who raised the issue about BritRuby — bounced back fine from the controversy caused by the 2009 talk Perform like a pr0n star. They don’t seem to have had any trouble finding more sponsors for subsequent events.

So the question is: Why was BritRuby really cancelled?

Update: Chuck Hardy, one of the organisers of the event, says via email: “I will be releasing a personal statement shortly.”

Update 2: Avdi Grimm has posted On BritRuby, an essay about the cancellation of the event. The most interesting part is this:

So I started asking around. I thought of all the prominent non-white-dude Ruby conference speakers I could in the space of a couple minutes. Just people who came easily to mind, nobody too obscure. I wanted to know if they had been invited to be part of that initial group of 15, and had said no.

Sandi Metz. Bryan Liles. Reg Braithwaite. Angela Harms. Sarah Mei. Katrina Owen (Norway). Keavy McMinn (Scotland). None of these people were invited to be part of the initial line-up. In fact, I couldn’t find a single woman or minority Rubyist who had been invited to be part of that 15.

This suggests to me that, if concerns about diversity really were to blame for the conference’s cancellation, the only reason the organisers could have for shutting down the conference is their own shame at not being inclusive enough. That, or fears about appearing to be including a ‘token minority speaker,’ a concern mentioned in the pseudo-official response linked above. But as far as I know, the speaker lineup was not yet complete: there were still a lot of talks planned that had not yet been announced, that were presumably to come from the Call for Participation. If there was any point at which to include speakers from more diverse backgrounds, the next batch of talks would have been perfect.

Now, I understand that accepting talks from minority groups only after a controversy has been raised may stink of tokenism a bit. I agree with Grimm, though, that any discrimination in the speaker lineup that was initially announced was probably not deliberate. Not wanting compare apples (invited speakers) to oranges (accepted proposals), I’d happily believe a denial of tokenism with regard to the latter.

Update 3: Chuck Hardy has posted his personal statement as promised. In it, he seems to send mixed messages: one moment he says that no sponsors had pulled out; he also seems to suggest that none had threatened to pull out, and defending them from blame:

Firstly, I would like to categorically state that none of our sponsors had officially pulled out of the conference. Running a conference of this magnitude takes time, effort and money. We were lucky enough to be able to secure some amazing sponsors who believed in what we stood for and who were willing to support us.

The next, he is citing concerns about sponsors pulling out:

However, I was not prepared to put myself in the position of legal liability and cost ramifications if a sponsor were to pull out under social media strain.

And finally:

I stand by my decision as I will not condone or be apart of any personal racial and sexist accusation. I was not prepared to provide a conference that was tarred with such accusation.

I have emailed Hardy with some questions about his statement.

Update 4: I just got off the phone with Hardy. He told me that in addition to the two announced sponsors, there were a lot more companies sponsoring the event, and it was them, not On The Beach or globaldev, who expressed concerns about the controversy on Twitter, and were worried about the potential defamatory results of an association with the conference given the issues about diversity, and the possible accusations of racism and sexism attached to them. The contracts which had been signed for the event have all been cancelled, and Hardy himself is now personally financially responsible for any non-refundable charges associated with those contracts; the sponsors are being refunded in full.

15 speakers had been announced; 5 had yet to come from the Call for Proposals. The initial 15 were chosen from a list of 40 potential invitees who were selected over discussions about who, ideally, the best, most interesting speakers could be at the event. The 15 that were announced were the 15 who agreed to speak. Initially, there was a bias towards British speakers, that being the focus of BritRuby as an event, but they decided to open it up worldwide to get the best speakers they could for the event. Hardy himself was not involved in the decisions about who to choose from the CfP, again to avoid bias: he could be accused of discrimination against speakers flying in from other countries because it’s his responsibility to find the money to pay for their flights. According to Hardy, they had some very interesting proposals from Brazilian speakers which were to be announced as talks.

Hardy denies any deliberate discrimination. He also denies any emotional (shame / stress / fear) reason for calling off the event. He also cited the diversity of the organising team.

It takes time to build a successful blog. In order to have a large income, you need to have more audience to visit your website. You can never achieve it overnight because there are more things to talk about. If you wish you will make blogging as a full time job, then maybe you should try to take startup internships first. In that way, you will be knowledgeable enough most especially if you don’t have any experience yet. You should realize the ups and downs of your chosen field. Besides, running a blog is just like running a business.

Well, the success of blogging may also depends on the network as well as the content. Of course, if your blog could be understood well by many people, then they will most likely visit your blog more often. It should also be interesting so that it can lure more visitors. More equally, blogging requires connection with fellow bloggers so that you can also learn from them. However, you should be aware that your income will not be consistent because there will always be some fluctuation every month. Although it is not a bad thing, you need to adjust all the rime.

This post will be revised as I find out more information.

How to do anonymous proposal submission.

Permalink • Read Later

Because of the BritRuby 2013 fiasco, I got thinking about how you could prove that you didn’t discriminate in favour of or against anyone when you selected the talks to accept. Anonymous submission of papers would be one way to do it, but I’m not sure if it’s the best way. Either way, here’s a method I quickly thought up for proving the anonymity of the selection process.

If you make each submission completely anonymous, how do you let the speakers know that their talk has been selected? How do you make sure no-one is falsely claiming to have authored a session proposal? How do you make sure the organisers aren’t collaborating with anyone outside, and the actual submission process isn’t simply a front for a behind-the- scenes process of choosing speakers another way? This method solves those problems.

Each proposal has a title and some other pieces of information. It’s also assigned a unique, totally random identifier. The proposer provides the title, the rest of the information about the talk, and a password. All this is sent to the reviewers for consideration. (The password is hashed, naturally.) He also provides a special ‘authentication phrase.’

For the purposes of this method, a submission consists of three things, only one of which is relevant to the people considering the proposal: an identifier (not known to the proposer), the title of the talk, and an auth phrase (not known to the organisers). These three are hashed together to create the public hash for the proposal, which the proposer is encouraged to share publicly once his proposal is submitted. (If he doesn’t feel comfortable doing this, he can share it after the talks are selected.) The hashes for all talks submitted are available online in a document anyone can read.

Once the selected talks have been announced, their titles and hashes are revealed together by the judging group. (Along with any of the further info collected from the proposer that needs to be published.) Then the proposers use their passwords to identify themselves and reveal their auth phrases to the organisers, which verifies their identities. They can then provide more personal information about themselves so the organisers and attendees know who will be giving the talk. The unique application identifier for all talks is also published, and the speakers and rejected proposers can reveal their auth phrases, so they (and the rest of the world) can use the hash to prove that all the talks were submitted by this process.

The main problem with totally anonymous submission like this is that you don’t know who you’re turning down. For a Ruby conference, what if you turn down David Heinemeier Hansson or Yehuda Katz because you couldn’t recognise their proposals? Of course, one could always go with a mix of talks submitted through this system and a couple more pre-invited speakers, but that leaves one open to allegations of discrimination in the selection of invited speakers.

Speaking skills.

Permalink • Read Later

I wasn’t sure whether to post this: it seemed kind of self-centred and not really relevant beyond my talk at ELC 2012. But I’ve wanted to address the subject for a while. This is somewhat incomplete, but it’s all I’ve had time to think about it.

I’m a bad public speaker. I either over-prepare or I under-prepare, and I tend to forget a lot of my material in the heat of the moment no matter what. In the most recent case (which has been a common scenario), I compulsively over-prepared, fearing being unready to give my talk. This ended up being so bad that what happened was this: I had some notes on paper, but because I had a lot of my talk in memory, I was able to skip most of them. But I missed a lot of the nuanced points I’d written down.

Then I’d hit a point where I couldn’t remember what I was supposed to say next. So I looked at my notes, but I’d gone fast from memory and had to flip several pages to see where I was up to. That caused a break in my talk. Then, later, I realised I’d gone out of order and missed almost an entire section out, so I had to go back. The result was that my talk, instead of being a neatly informative upside-down pyramid, was more of a confusing upside-down cello.

I’m going to attempt to right this particular wrong by posting an essay version of my talk (which was actually how I wrote it in the first place) on this site in the next couple of days. I’m sure when the video of the talk goes up I’ll realise it wasn’t that bad.

(The other problem with my talk was that I didn’t realise how disagreeable some of the things I was saying were to my audience. I get the impression that talking about a new “practical Lisp” to a crowd that turned out to be full of Clojure fans was not such a great idea. Doubly so when you’re not clear about what differentiates your language from Clojure.)

In the general case, what could I do to improve this? I feel actually that I wish I didn’t have to have slides, and that they directed the flow of my talk in a very un-natural way. But I had to show off code examples somehow, and with no working implementation that accurately reflects the current state of the language as I envision it, live coding was not an option.

Slides are out in future, I’ve decided, as are notes with pages. I’m going to try using a teleprompter — not to read from directly, but so I can have my notes always roughly keeping pace with where I am in my talk, without having to do anything to advance them. (Ideal app: something that uses speech recognition to work out where I’m up to by looking for key words in my speech and my notes, and advances automatically.)

Coming later this week:

  • A report on Strange Loop.
  • The aforementioned essay version of my talk.

The dilemma of delays.

Real artists ship.

Permalink • Read Later

You embark on a software project. Due to one or more of the following:

  • you didn’t previously have much experience in writing this type of program;
  • you made some major architectural mistakes at the start, that became baked in as you put more layers of abstraction over them;
  • you bet on the wrong technology;
  • you’re a slow programmer anyway;
  • you have other stuff to do (or think you have other stuff to do)

your project encounters a delay. You have to rewrite large chunks of your software.

You had stupidly told other people about this project already, putting yourself in a position where failure would be embarrassing, not just because of others but because of you: you’re ashamed of yourself that you can’t finish such a ‘basic’ project.

The people who are hopefully expecting the release of your software get impatient. They become more expectant: “Wow, David’s been working on this thing for months, it must be the best software in the world!”

It is not the best software in the world. Two months in, it could look just the same as it did two weeks in, because you had to rewrite for some reason. And because you’ve spent two months on it, your expectant users are expecting a product to come out that is already feature-rich, while it could still just be very minimal — after all, you rewrote from scratch (or refactored, or whatever) just two weeks ago. Fortunately, your new refactored app is well-architected and you should just be able to add two months’ worth of features in a weekend, right?

Well… no. Your users are expecting a product that is at least somewhat mature and you’ve got a two-week–old version that’s probably still full of bugs. If you do implement two months of features, it’s now been four months and your prospective users are expecting much more!

This is a classic catch-22. The standard lean-startup–ish, “just get it done” advice runs something like this: shipping is a feature; you shouldn’t put time into extensive refactoring efforts because the user won’t notice them; get it done, get it out and crush your competitors.

But the specific brand of this I’ve been struggling with lately is the sort of stuff that’s immediately obvious to users, and is actually a “show-stopper”: imagine a network system that was full of race conditions and other deadly bugs that meant much of the vital information it has to carry get dropped on the floor and not transferred to its destination. The two possible solutions to this are: fix the dozens and dozens of bugs one by one (and these are race conditions and deadlocks and the like — devilishly tricky to track down) or start over / refactor with a better architecture that wouldn’t just not have these bugs, but would by design be immune to them: it simply avoids using any coding styles that would be vulnerable to them.

In this particular project, which has been underway since March, I’ve encountered numerous scenarios like this where, due to my lack of understanding at the time of what has turned out to be a quite complex genre of program to write (in terms of reliability, maintainability, and speed), I’ve made a fundamentally bad decision early on and had to change my approach significantly, but only after entrenching those areas of the codebase.

Because it’s taken so long to get to what still feels like a stupidly early stage in development — much to the chagrin of my patient co-developer — I’m embarrassed that we haven’t shipped yet, though we’ve come dangerously close. At this point I feel like I’ve just wasted a part of my life and I’ve already failed, even though I have a good application in the works and it really, genuinely is now nearly ready to ship. Even though it’s been six months, and we have the feature set you’d expect from a product that’s maybe only one month old. I’m angry at myself for wasting so much time and money on this already. And, funnily enough, I’m super-annoyed that we haven’t got to the bottom of our Lenin document yet. Truthfully, we’re barely 5% through it. But we’ll pull through.

On Pat Dryburgh’s video about John Siracusa’s Mountain Lion review.

Permalink • Read Later

A sunny Wednesday in San Francisco, and WWDC was in full swing. And the internet told me that if I showed up in Yerba Buena Gardens at 12:45, I could star in a Pat Dryburgh production: the sequel to 2011’s critically-acclaimed Preparing for John Siracusa’s Review of OS X Lion. Count me in!

I told Josh that I was heading off to Yerba Buena Gardens, and asked if he wanted to come.

JOSH: “What for?”
DAVID: “Oh, I’ll sit in the shade and work for a while, and then I’m gonna be in a video some guy’s making.”
JOSH: “Oh, what video?”
DAVID: “Do you remember last year, there was that video about John Siracusa’s OS X review? The review that’s always about 20 pages long?”
JOSH: “No, I don’t think I’ve seen that …”
DAVID: “Well, he’s making a sequel for the Mountain Lion review. I’ve volunteered to be in it.”
JOSH: “Oh, cool!”
DAVID: “There’s free lunch, as well.”
JOSH: “Great! I’ll come along!”

We caught the 30 from North Beach to 5th & Howard then walked up to the Moscone Center, by which time it was 12:45 anyway. Pat said he’d be in a bright pink tank-top, which would have made him easy to spot, except that we walked straight past him and only noticed our mistake when we looked around and saw him right where we’d just been.

To my great surprise Siracusa himself was there, and, after one or two more people arrived, we headed out onto the main grass area on the park to start shooting. Siracusa was in a rush so he only had time for a cameo role. Pat explained that we’d line up in a triangular formation. I took my place at the end of the back row. Josh stood at the sidelines, not really expecting to be included in the video.

Then Pat turned to him and said, “Hey, can you come and stand here?”

So now Pat, who didn’t realise that Josh hadn’t really volunteered to be in the video, had asked Josh, who hadn’t seen the original and didn’t really understand the theme of the video at all, to line up and take part. Which he did.

Now we started doing “finger push-ups.” Josh had no idea what the hell was going on, but I think he quickly got the hang of it. Siracusa had to run, so, with his cameo role wrapped, he left the rest of us to carry on doing finger push-ups.

Then we started doing “exercise” in the form of picking up our iOS devices from the floor and marching while we read on them.

Finally, we shot the scenes on the steps and on the bridge, including the “Mountain Lion!” high-five. Josh was still extremely confused. He had been expecting, as he told me later, “a sensible interview with sensible people at sensible WWDC.” He certainly didn’t expect to be featured in a workout tape. We grabbed lunch with Pat and the gang, which was super-cool. Then we headed back home, and I showed him the original Lion review video.

At which point he realised the full scale of what I’d dragged him into.

Anyway, it was a pleasure to work with Pat, who is an extremely friendly and funny guy, and his team; they are professionals and true gentlemen. You should go and work at his startup if you have any self-respect whatsoever. (I don’t, clearly.)

The video: Preparing for John Siracusa’s Review of Mountain Lion.

Next year: Fireworks. Explosions. For real. You should take part.

The corruption of the getting-kids-coding movement.

Permalink • Read Later

Young Rewired State is a national event for under-18s to gain confidence in programming and meet other coders of their age. A side aspect of the event is its competitiveness: participants’ projects are judged and the best are awarded prizes.

As a supposedly coding-oriented event, you might be surprised to learn that last year’s overall winner was not coding-related at all, but a Minecraft map. Here’s a participant in another hack day for young people being similarly productive. Several other winning projects were not even working apps, but just concepts sketched out in PowerPoint. And a judge in this year’s event will by Lily Cole — famous not as a technological innovator or even investor, but as a model and actress who now has some unspecified role in an unlaunched startup.

Clearly, there’s something going wrong with the movements to get kids coding. The actual trend is towards ‘get kids gaming,’ or more kindly, ‘get kids coming up with ideas.’ Anyone can come up with an idea for an app — just ask anyone with shiny shoes at a San Francisco hack-space1 — and building confidence in coming up with ideas just gives us a new generation of excitable would-be entrepreneurs.

So here is what I predict will happen to the movement to ‘get kids coding’ over the next year or so: the government’s new initiative will be corrupted by companies like Microsoft and (the ghost of) Sun to push .NET, VB, C#, and Java on kids; meanwhile the activism of hackers trying to get the really good technologies like Ruby and Python into schools will be corrupted by the temptation to turn ‘extracurricular coding clubs’ into LAN parties.

The end result will be that kids in school will be subjected to crushingly dull lessons on programming, and those few nerdy kids recognise some interest in the field will try to find groups and events to support their interest, and just find a bunch of jocks playing games.

The problem is partly that the get-kids-coding movement is saturated with people who aren’t themselves developers. Seldom are the leaders of these groups bona-fide developers themselves. Rewired State itself now has two management boards (apparently one wasn’t enough) with only one actual developer between them, Sym Roe, who is also the only person on both. (Although Thayer Prime and Ben Nunney were both developers in previous lives, and are now effectively Developer Evangelists.)

There are two sides of the issue that need to be addressed: the power of Microsoft, Oracle, et al. to push boring material into schools,2 and the conversion of programming clubs into gaming clubs.

The solution to both issues is simple: the hackers in the grassroots getting-kids-coding movement ought to draw up their own curriculum, or guidelines for a curriculum, and promote it heavily. (Look, I even started one a few months ago.)3 The goal of this would be make the real developers heard. Teaching C# or Java is useless: almost no startups use these languages, at least not successful ones. And today’s successful startups are tomorrow’s large-scale employers, who probably won’t consider an applicant who doesn’t know the language they use.

And in fact, the startups’ languages have another advantage, which is that they’re more fun. Teaching coding boringly is worse than not teaching it at all. If kids are bored with coding, they won’t even be interested enough to go to the after-school clubs, let alone become software developers in their future career. There’s just too much boring cruft in Java and C# for it to be interesting, whereas Ruby and Python just get out of your way and let you make a cool thing.

The ideal computer science curriculum should be an open-ended invitation for kids to make things which make them, in the eyes of their friends, ‘cool.’ If they make a game everyone likes, that’s cool. If they build some kind of social network for their friends, that’s cool. If they build a seven-layer multiple-inheritance class hierarchy, that’s not cool and it will just make programming seem uncool. Programming should be about the joy of creation, and how amazing it is to make the computer say your name or draw a funny picture — that’s how you make software developers.

When kids are hacking games instead of playing them, a different culture altogether emerges: one of collaborative cooperation; of kids teaching each other how to make neat stuff. I know this because I experienced it myself in the first YRS that I attended.

I have a feeling that there is no way, realistically, that coding in schools is going to be taught without making me a bit annoyed. But let’s try to make it not completely suck, otherwise we may as well just hand out free copies of Learn to Program to kids and hope that some of them take an interest, because that would be more effective in getting kids into software development careers.

I’m thinking about my own position here, and how interested I would have been in programming if this stuff had been taught at my school. The number of bad curricula that put me off working in areas that could have formed a major part of my career is innumerable, and a curriculum that taught me how to build applications in Java would have almost certainly put me off the life in computing which I now enjoy.

  1. He might even ask you if you will be his technical co-founder. 

  2. I’m not saying that Java or C# are bad languages.4 It’s just that somehow, I can’t see kids being excited about creating AdderVisitors and HelloWorldFactorys and MyFirstClassInterfaces, which is the sort of cruft that these languages encourage you to build. All that design-patterns crap seeks to distract from what kids should actually be learning, which is how to make useful tools and programs on their computer. 

  3. Note that this is the joint work of me, Josh Pickett, and Michael Mokrysz. I don’t think either Michael or Josh would oppose its use in any way, but it’s probably best to check with them. 

  4. They are bad languages, by the way, but I just don’t want to stir up that controversy in this article. The people who get annoyed by this are probably too stupid to read footnotes, especially nested footnotes.