In Computing Machinery and Intelligence, Alan Turing describes the famous Turing test for detecting machine intelligence. Did you know that Turing’s thesis was heavily influenced by Ada Lovelace’s critique of Babbage’s Analytical Engine, wherein she states that “the Analytical Engine has no pretensions to originate anything,” arguing that computing machines do not exhibit creativity? You can read more about Lovelace’s critique of the possibility of machine creativity, and how this critique informed Turing’s work on machine intelligence in my paper, Computing Machinery and Creativity.

Happy Ada Lovelace Day!

I’m a talented software engineer. I have a good deal of application programming experience on Windows, Mac OS, Linux, iPhone, Android, and the Web. I’m crazy about style guidelines, correctness, functional decomposition, self-documenting code, explicit documentation, code review, unit tests, etc. I’m confident that for most application codebases, I could learn my way around quickly enough to make meaningful bug fixes and other improvements.

Despite being good at these things, the barrier to entry for fixing a bug in any given application (paper cuts are a very good example of the kind of bug I’d like to fix) is still very high for me. I am lousy at chasing down dependencies, maintaining clean build environments, generating patches, and dealing with unfamiliar version control systems. I know next to nothing about packaging or publishing PPAs. Some of you may read this and think, “well, that’s your fault–stop complaining and learn these things,” but I contend that there are very many talented, opportunistic programmers just waiting to contribute by doing what they do best–writing code. These eager programmers are similarly hindered by this barrier to entry, and we would benefit more by accommodating them than by insisting that they accommodate us. Furthermore, we have the ability to completely automate the stuff that isn’t software development and hide its complexity from developers–in fact, we’re already mostly there. To illustrate my point, I present my ideal user story for fixing a paper cut.

I want to fix bug #511767, “‘Hash for Duplicates’” is tech-speak.” F-Spot has a great feature for finding duplicate images in your photo library and getting rid of unwanted copies; however, this useful feature is exposed to the user under the label “Hash for Duplicates.” The user likely doesn’t know what hashing is. Besides, the user wants to find duplicates, not hash them–hashing is just an implementation detail. To fix this bug, I click “Quickly fix this bug,” right on the bug report in Launchpad:

Automagically, an application on my machine opens to handle the URL behind the Quickly fix link (e.g. lp://fix/?bug=511767). This application performs the following steps on my behalf:

1. Runs apt-get build-dep f-spot to prepare my machine to build the package affected by the bug.
2. Runs apt-get source f-spot to download a source package that can be built on my machine.
3. Opens the f-spot source in Eclipse*, where the source package is built for me.
4. …and presumably cleans up the mess after I’m done.

* Why Eclipse and not [insert your favorite IDE/editor here]? Because Eclipse is extensible, popular, cross-platform, and supports many different languages, but most of all, I picked Eclipse hoping we could just skip the endless debate where everyone argues that we should use the IDE they wrote “Hello, World” in once.

With the exception of typing my password if needed, the next thing I should see after clicking “Quickly fix this bug” is the F-Spot source package open and built in Eclipse, where I can “quickly fix” the bug:

With one click, Eclipse builds and runs the project to let me test my changes:

Looks good to me! Time to submit my changes to the Launchpad bug report. With one additional click, Eclipse can push my changes to a PPA, publish a Bazaar branch and generate a merge proposal, or simply attach the patch to the Launchpad bug report. I choose “Attach Patch to Bug Report,” so Eclipse creates a patch, opens my browser to the patch submission form on the Launchpad bug report, attaches the patch, and leaves it to me to add a comment and submit:

To summarize, this user story consists of the following steps to create, test, and submit a patch for a small bug:

1. Click “Quickly fix this bug” on the Launchpad bug report.
2. Edit the source of the corresponding package in Eclipse.
3. Build the project and test the changes.
4. Submit the patch and comment back to Launchpad.

Which version control software does upstream use for this package? How do I get the code? Which build environment or IDE do they recommend? What dependencies does the package have? How do I use debuild? I shouldn’t have to know the answers to any of these questions to fix the bug in question. Can we make this quantum leap forward in our bug workflow? Even if we were to enable “Quickly fix this bug” for only a handful of important packages, this would be a tremendous force in improving the quality of software in Ubuntu.