Can you develop research software on an iPad?

I’ve just written up a blog article for the Software Sustainability Institute about research software development in a “post-PC” world. (Also available on my project’s own site.)

Apart from using the terms “post-PC”, “touch tablet”, “app store”, and “cloud” a disgracefully large number of times, this article sets out a problem that’s been puzzling me for a while.

We’re increasingly trying to use, for everyday computing, devices that are locked down to very limited software distribution channels. They’re locked down to a degree that would have seemed incomprehensible to many developers ten or twenty years ago. Over time, these devices are more and more going to replace PCs as the public idea of what represents a normal computer. As this happens, where will we find scientific software development and the ideals of open publication and software reuse?

I recognise that not all “post-PC” devices (there we go again) have the same terms for software distribution, and that Android in particular is more open than others. (A commenter on Twitter has already pointed out another advantage of Google’s store that I had overlooked in the article.) The “openness” of Android has been widely criticised, but I do believe that its openness in this respect is important; it matters.

Perhaps the answer, then—at least the principled answer—to the question of how to use these devices in research software development is: bin the iPad; use something more open.

But I didn’t set out to make that point, except by implication, because I’m afraid it simply won’t persuade many people. In the audio and music field I work in, Apple already provide the predominant platform across all sizes of device. If there’s one thing I do believe about this technology cycle, it’s that people choose their platform first based on appeal and evident convenience, and then afterwards wonder what else they can do with it. And that’s not wrong. The trick is how to ensure that it is possible to do something with it, and preferably something that can be shared, published, and reused. How to subvert the system, in the name of science.

Any interesting schemes out there?

How Much Legacy Code Have You Written This Week?

I recently bought a copy (based on a recommendation) of Michael Feathers’ 2005 book Working Effectively with Legacy Code.

This excellent technical book is largely a compendium of refactoring strategies to help software developers insinuate unit tests into existing code.

What I found most striking, though, is a position stated right at the start of the book.

Most programmers have a broadly intuitive idea what “legacy code” means. It’s typically a euphemism for code that they resent, because it’s old and crufty and they have to maintain it unwillingly. There may be a hint of the positive meaning of “legacy”—code handed down to you that does at least work, which is why you have to maintain it. In my mind there’s also a suggestion that the code is alien in some way—written for an obsolete platform or in an obsolete language—which contributes to the difficulty of managing it.

Feathers dismisses most of these possible definitions, writing

In the industry, legacy code is often used as a slang term for difficult-to-change code that we don’t understand. But over years of working with teams, helping them get past serious code problems, I’ve arrived at a different definition.

To me, legacy code is simply code without tests.

[...] With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

That’s pretty uncompromising, but it certainly gives you perspective.

If you take this point of view, then every line of code you write that lacks tests—proper tests that properly test, and that other people can run—is an immediate, direct contribution to the sludgy mountain of cruddy code that nobody really understands and that probably doesn’t work.

(Of course, code with tests can still be useless. But at least it has potential.)

I’ve written a lot of legacy code over the past few years. I’ve only quite recently started unit testing routinely in new code I write, and I still need to crisp up my development practice—fewer lines of code per task, more of them demonstrably working. I might not find Feathers’ definition of legacy code entirely satisfactory as a cultural one, but it’s a highly useful stimulus.

iPads in schools

Fraser Spiers remarks, in a review of the Google Nexus 7 tablet:

My experience with two years of iPad in school is that the iPad can cover 99% of everything we want to do with a computer in school… the iPad can replace the computer suite

I think the radical nature of his observation has to do with the replacement of the desktop computer in dedicated labs—the iPad is already widely proposed and increasingly adopted as an assistance to learning for pupils outside the computer suite.

Viewed close-up, this seems like a good thing. iPads are generally cheaper,  more reliable, and easier to get to grips with than traditional PCs, are portable enough to be used across teaching disciplines, and make a wide range of software very easily available.

But imagine that, ten years ago, someone had proposed:

  • that in future, schools in the UK and elsewhere would buy all of their computer hardware and most of their software from a single American company;
  • that software for these computers could not be used with hardware made by anyone else, never mind with other operating system platforms;
  • that software for these computers could only be obtained through the company that made the computers, and that installing it would require entering a contractual relationship with them;
  • that these computers could not be programmed natively using the computer itself: prospective application programmers would first need to buy another, more expensive computer from the same company, enter another contractual relationship with them, and in most cases also pay them;
  • that GNU-style Free Software would be forbidden from running on them;
  • that the company in question was known to have designed this environment quite deliberately and had a record of squashing attempts to work around its limitations;
  • and that these computers would be used as a standard teaching platform across all disciplines, and would also be the platform on which computing as a subject was taught to children.

How would that have sounded?

SoundSoftware 2012 Workshop

Yesterday the SoundSoftware project, which I help to run, hosted the SoundSoftware 2012 Workshop at Queen Mary. This was a one-day workshop about working practices for researchers developing software and experiences they have had in software work, with an eye to subjects of interest to audio and music researchers.

You can read about the workshop at the earlier link; I’d just like to mention two talks that I found particularly interesting. These were the talk from Paul Walmsley followed by that of David Gavaghan.

Paul is a long-serving senior developer in the Sibelius team at Avid (a group I’m interested in already because of my former life working on the notation editor aspects of Rosegarden: Sibelius was always the gold standard for interactive notation editing). He’s an articulate advocate of unit testing and of what might be described as a decomposition of research work in such a way as to be able to treat every “research output” (for example, presenting a paper) as an experiment demanding reproducibility and traceable provenance.

Usefully, he was able to present ideas like these as simplifying concerns, rather than as arduous reporting requirements. At one point he remarked that he could have shaved six months off his PhD if he had known about unit testing at the time—a remark that proved a popular soundbite when we quoted it through the SoundSoftware tweeter.

(I have an “if only I’d been doing this earlier” feeling about this as well: Rosegarden now contains hundreds of thousands of lines of essentially untested code, much of which is very fragile. Paul noted that much of the Sibelius code also predates this style of working, but that they have been making progress in building up test cases from the low-level works upward.)

David Gavaghan took this theme and expanded on it, with the presentation of his biomedical project Chaste (for “cancer, heart, and soft tissue environment”). This remarkable project, from well outside the usual field we usually hear about in the Centre for Digital Music, was built from scratch in a test-driven development process—which David refers to as “testfirst”. It started with a very short intensive project for a number of students, which so exercised the people involved that they voluntarily continued work on it up to its present form: half a million lines of code with almost 100% test coverage that has proven to avoid many of the pitfalls found in other biomedical simulation software.

Software Carpentry

Elsewhere on my tour of the north-east, I’ve been helping out this week at the Software Carpentry boot camp at Newcastle university.

These events are aimed mostly at postgraduate research students who need to write software for research. They try to provide just enough training in real-world software development techniques to get people started with writing reliable, testable code and managing it properly.

The idea is not so much how to program, as how to program efficiently—choosing and using sensible tools, and applying coding techniques that have been shown to improve productivity. It’s absolutely not a software engineering course, but rather a course on applying a few software engineering techniques to make for better scientific work.

Although the course is only two days long, it gets through an introduction to shell scripting, version control, Python programming, test-driven development, pair programming, and databases with SQL, as well as a certain quantity of philosophical material. Everything is hands-on, with attendees “coding along” with the presenter. So it goes along at a fair pace, and although no particular experience at programming is necessary, an analytical mind and a lot of attentiveness are.

I presented the version control segment at this and the previous workshop, using Mercurial, EasyMercurial, and Bitbucket. It was a bit seat-of-the-pants the first time around, but had settled in a little the second time. Even so, it’s a very ambitious segment: we have two hours to go through a real, working editing process using the EasyMercurial user interface, Mercurial command-line, and Bitbucket web site, working with others and resolving merge conflicts, for an audience who have largely never encountered version control software before. When it works out, of course, it’s very satisfying and we had generally encouraging feedback from the attendees in Newcastle. (If you were there and have any thoughts on how to do better, please do get in touch.)

The Software Carpentry project, started by Greg Wilson around fifteen years ago, is an open source scheme that anyone can get involved with. The Newcastle workshop was the latest in a long line of presentations of Software Carpentry material around the world, but it was the first in the UK to have been given without having Greg’s experience on hand (he lives in Canada) and thus was something of a learning experience for the presenters as well as the participants.

That’s sort of the idea, though, so if you know your onions and like the idea, you might like to try helping out in a future workshop.

See the brief report from my project, or feedback from attendees.