I am Zef

Software Engineering is an important field. Millions and millions are spent every year on developing software even though, frankly, we suck at it: Software is delivered too late. Software has bugs. Software is completely incomprehensible to its users.

So, companies and governments around the world invest in software engineering research. Professors and PhD students are hired to investigate the problems and come up with solutions. The solutions are written up in academic papers and published to academic conferences. Academic conferences are mostly attended by other academics, listening to each other, collaborating, sharing ideas.

So much for the theory.

I myself am part of this system. I’m a PhD student, 3.5 years in. I have published papers, and I have attended conferences. When I submit a paper to a conference about 3-4 people peer review it and, ideally, accept it. It’s then published to conference proceedings, available in book-form, as well as online, typically behind a pay wall (downloading one of my papers individually costs around $10). Therefore, my paper readership is in practice mostly limited to other academics, whose universities pay big bucks to get access to conference proceedings.

When publishing to a conference, you also get to go to go and talk publicly about your paper for about half an hour. There will likely be a few dozen people in the room, half of which are typing away on their laptops.

The thing is, in our group, a lot of us build tools. The target audience of those tools, ideally, is not the academic world, it’s the software engineering world — not people talking or researching it, but the people doing it. That is, while we are writing papers for academics, we don’t really reach our target audience directly. Sure, indirectly, when your ideas are good, they may reach the mainstream one day. But that will likely be a matter of years.

I’m doing work in the programming language space — how many languages you use today came from academia? A few (a recent one is Scala), but most were developed in industry.

Why?

As it turns out building tools that are robust and reliable take a lot of engineering work. Research is only a small part of it, and that’s a problem because you cannot publish engineering work, you’re an academic, you publish research. All the time you spend engineering on your tools, you’re not spending researching and writing papers. Published papers are currency. I must add here that in our group they’re really good about these things, we get a lot of time to do engineering without a professor breathing in our neck yelling “publish, publish!” We are encouraged to build real, useable tools. Still, intrinsic in the system is that for an important part success is measured by publication count. My PhD thesis is to be filled with published papers.

What’s the result? A bunch of tools are out there that, even if you wanted to, you cannot even download, or if you can, don’t compile, and if they do, are not documented. Abandoned after the paper was published.

But I digress.

Beside publishing papers, I have a blog. Over the past years I published a few blog posts that were related to my work. Some of them ended up on the frontpages of programming reddit and hacker news and many of them were read more times in one day than all my papers together will likely be read over my life time. And the readers are programmers — exactly my target audience. Sure, some of these readers called me names — but I like to think I planted some seeds here and there. I believe that my blogging has done more in terms of “changing the world” than any of my papers (so far, at least).

I’ll give three examples.

1

A year and a half ago I published When Rails Fails, which was a small part of the related work research I did for this paper (have you read it?). My main message was: Ruby on Rails is not very forgiving when you make mistakes, you often get horrible error messages at runtime. Sure, I got half the Rails community taking a dump on my porch, but the blog article raised an issue: you should’t have to put up with this, the bar must be raised. Some people picked it up and were discussing solutions. Not sure if this changed anything, but it’s a start.

2

A year ago I published persistence.js: An Asynchronous Javascript ORM for HTML5/Gears, a post about a little Javascript library that I needed for what eventually would become mobl, but did not yet exist. persistence.js is more of an engineering project than a research project. There were some new-ish ideas, but basically it was just implementing an Object-Relational Mapper in Javascript. Nothing to write a paper about. Although persistence.js didn’t make a splash entrance, slowly but steadily a community grew around it, and today persistence.js it being maintained by about a dozen contributors and it expanded from the browser to the server, where Javascript is rapidly taking off with node.js. Recently I got a thankful e-mail from one the guys behind Readability who use persistence.js in their mobile application. No paper, but impact on the industry? A little, at least.

3

Lately, we have been struggling with mobl, the language for mobile development that launched this January. Interest in mobl is been pretty incredible since I built a reasonable website, started blogging about it, and wrote an InfoQ article. And thus I spent the past few months mostly fixing bugs, adding features and providing support the growing community of users. I gave a few talks about mobl, both in an academic setting and in industry and everywhere the feedback has been overwhelmingly positive. People are impressed with this stuff. Yet, the paper we wrote about mobl and submitted to a big web-related academic conference got rejected. “Where is the research contribution here?” they asked. Mobl is a nice mashup of programming language ideas, yet none of them are truly new. You may not have seen them all before, but that’s likely because they were published in academic papers, and who reads those during breakfast? Not me. The trick, now, is to somehow package the mobl story in such a way that our future reviewers will see it as enough of a research contribution to publish it. We’ll see what happens there.

Yet, I believe, even if mobl for some reason would not be the next big thing (can you imagine? ;)), our real audience will have seen it and thought “that one thing there, that is a really cool feature”. They will look for that feature in future languages and frameworks, because they know it exists — the bar has been raised.

Now that I mention it. If I’m being extremely cynical, for an academic knowing that “that one language had that cool feature” may be a reason not to implement it, because it’s not novel, it’s not a research contribution. But maybe I’m stretching it a bit.

So?

“What’s your point, mate? Set fire to the whole institution they call ‘academic research’?”

Meh. Let’s not do that just yet. I do think, but this depends on the kind of research that you do, that academics should talk to their real audience more. Don’t only submit papers to academic conferences, but industrial conferences as well. Blog. Create screencasts. Somehow negotiate time to build a real, usable, stable tool with a website that uses at least one feature from HTML 4.

And to those who give out research grants: expect more than academic papers, expect usable products and the PR that goes with it.

There’s so much interesting work happening in academia and the people that it affects simply don’t get to see it. It’s a shame.

We can do better than this!