Opinion on The Carpentries

The Rest Is Yet To Come

Sat, 29 Oct 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I co-taught an instructor training workshop earlier this week, then taught a second one on my own a couple of days later. I made some pretty big mistakes in both: I kept interrupting my co-instructor in the first, while in the second, I told too too many stories, made jokes about hipsters and Javascript programmers when I’d told participants not to belittle people in class, and shut down discussion a couple of times when I had no authority to do so.

Programming as Theory Building

Sun, 23 Oct 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I was recently reminded of a thought-provoking but often-overlooked essay by Peter Naur from 1985 called “Programming as Theory Building” (scan here, plain text here). He suggests that, “…programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.” His thoughts on what programmers actually do, especially when modifying programs, seem directly relevant to most research software development. In particular, when the Jupyter Notebook and R Markdown are discussed as ways to make research more reproducible, I wonder if part of that is to encourage the programmer to make her theory of what she’s doing explicit.

Show Me Your Model

Sun, 18 Sep 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

As far as I can tell, there are no published studies showing that version control is better than mailing files around or sticking them in shared drives. I believe it is–I wouldn’t work on a project that didn’t use version control–but nobody’s ever gathered data, compared it to a model, and published the result.

One reason, I think, is that we don’t know how to measure the productivity of programmers. “Lines of code per hour” clearly isn’t right: good programmers often write less code, or spend their time on the parts of problems that have the highest thinking-to-coding ratio. Without some operationalization of “better” and “worse”, it’s hard to rank or compare alternatives.

We Still Can't Have Nice Things Together

Mon, 05 Sep 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Last year I used YAML and Norway to explain why why we can’t have nice things. We’ve just stumbled over a problem that has forced us to re-do some of the work we did to publish our lessons a couple of months ago, and which illustrates how openness can still be frustrating to actually do. Are you sitting comfortably? Then let’s begin.

GitHub can publish repositories as website.

If the user’s ID is gloom, and the project’s name is despair, then the GitHub repository’s URL is http://github.com/gloom/despair. If that repository has a branch called gh-pages, GitHub automatically creates a website at http://gloom.github.io/despair.

Complexity vs. Subtlety

Sat, 05 Mar 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I gave a lightning talk on Software Carpentry for the [OICR](http://oicr.on.ca/) yesterday, and in discussion afterward, [Jonathan Dursi](http://www.dursi.ca/) made an observation that I've been thinking about since. He wondered whether the key difference between commercial software and scientific software is *complexity* versus *subtlety*. For example, the software that manages workplace insurance payouts for the province of Ontario is complex because it has to handle every regulatory change since the mid-1920s. None of the its rules and exceptions are intellectually taxing, but by the time you turn them into a service, provide a dozen different interfaces for different business roles, and make the whole thing fault tolerant, the software is incredibly tangled.

A lot of scientific software is relatively straightforward by comparison, so long all you look at is the control flow. It’s the specific calculations that are hard: what differencing scheme or statistical test to use, what convergence criteria or significance measure to apply, and so on. And yes, there are a lot of fiendishly tricky algorithms in science, but they’re often hidden in libraries built and maintained by specialists who work and think like software engineers.

Come a Long Way, Got a Long Way to Go

Sun, 07 Feb 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

[Simon Oxenham recently reported](http://bigthink.com/neurobonkers/we-need-to-rewrite-the-textbook-on-how-to-teach) on [a new report](http://www.nctq.org/dmsStage/Learning_About_Learning_Report) from the National Council on Teacher Quality that examined how well teacher training courses and textbooks convey evidence-based teaching practices. The sad answer is, hardly at all:

The report finds that out of 48 texts used in teacher-training programs none accurately described fundamental evidence-based teaching strategies comprehensively. Only 15 percent had more than a single page devoted to evidence-based practices; the remainder contained either zero or only a few sentences on methods that have been backed up by the decades of scientific findings that exist in the field of educational psychology.

18 Months of Progress

Fri, 15 Jan 2016 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

[My talk at SciPy](https://youtu.be/1e26rp6qPbA?t=1748) in 2014 quoted one of our instructors as saying:

The most frustrating things for me are

people are more willing to submit new material…that to improve existing material or review another person’s PR and 2) instructors teaching bootcamps using other lesson material. This experiment in collaborative lesson development is doomed to fail if

people don’t make iterative changes to lesson material and 2) the end product isn’t used in live bootcamps.

18 months later, I’m very pleased by how much better we’re doing. Almost all of our instructors are now using our lessons rather than legacy material of their own. just as importantly, dozens of people have submitted pull requests in the last couple of months alone. Some of those are exercises required to complete instructor training, but others range from minor bug fixes to major refactorings.

New Words Needed

Sat, 26 Dec 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Titus Brown recently asked (on behalf of a friend) what people think of the term and practice of "hardening" software, by which he meant making research software more robust, more easily usable, and possibly scalable. Several people responded that "hardening" is usually used to mean "make more secure", and that what Titus's correspondent was really asking about was something we don't have a simple word for: making software ready for production use. As Morgan Taschuk wrote, this involves eliminating hard-coded paths, adding useful error messages, incorporating command-line flags to turn features on and off, and many other things that aren't really necessary if the program is only ever used by its author on her own machine and data, but are essential to institutional scale-up, i.e., to making the software usable by other people, in other places, on other problems.

More on Educational Engineering

Wed, 16 Dec 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In my experience, the term "educational engineers" doesn't seem to have caught on to describe any particular activity, but I can provide some examples of people bringing ideas from the research to inform teaching. There's a range depending on what counts as "building".

Educational Engineering

Tue, 15 Dec 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

One of the participants in this week's instructor training course mailed me to say, "[We] were discussing some of the ideas we were talking about in educational research and I feel like we are missing 'educational engineers'. Does this discipline exist? I feel like we don't really have the people to take the research that's been done and build something with it."

The answer is that we actually do have educational engineers: at the K-12 level, many of the people who write textbooks and other learning materials have lots of training in pedagogy, and the curriculum they create goes through the same sort of careful review that plans for a new dam go through. But that's usually not true in higher education: most of the people who write textbooks at the post-secondary level are domain experts with little or no training in pedagogy. And even in K-12, people with no background in education at all frequently overrule experts on both content and method.

Pulling In Those Left Behind

Thu, 29 Oct 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A common challenge that arises before or during a workshop is that participants' prior expertise in programming or broadly speaking their abilities of using computers for science is distributed randomly. At best, this distribution peaks at the expectations of the instructor. Usually, this distribution is quite wide and thus a considerable portion of the participants do lack the necessary predispositions for the workshop level, or have a slower learning rate or simply are too shy to ask questions. I recently taught a follow-up workshop to the Software Carpentry (SWC) Novice material and struggled to keep the pace of teaching at a level so all learners would come along. Given the feedback on the SWC mailing list (see the original post), this problem occurs quite often. Thus, this blog post is a summary of the discussion initiated among fellow SWC instructors on how to pull in those learners again that fall behind or how to pace/design a course so that a minimal portion of learners fall behind.

Code Review - a Needed Habit in Science

Wed, 28 Oct 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

More than a year ago, Marian Petre and Greg Wilson wrote an article about reviewing code, but I was not aware of it until last week when Greg talked about their findings in a workshop in London (though it had been mentioned here before). I have been reviewing code for years, however I have not realised that I was doing so till GitHub made it easy. Reading code from others feels the same as proofreading a Spanish text (or any other text), where you have to pay attention to the orthography, the grammar and whether it says what it's meant to say (or it does what it's meant to do).

Inserting Software Carpentry Graduates into Coding Communities

Mon, 19 Oct 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

One of the issues I'd like to see Software Carpentry tackle is what happens to learners after they've attended a workshop.

Journals as Repositories

Sat, 17 Oct 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I had a really good conversation yesterday with Cath Brooksbank and Sarah Morgan, who do training at EMBL-EBI in Hinxton. During the conversation we touched on CourseSource, a peer-reviewed journal in which people can publish undergraduate biology lessons—not studies of the lesson's effectiveness, but the lessons themselves.

This is a brilliant idea, and thinking about it has made me realize why I've never been excited about online lesson repositories. We already have repositories for the things academics do: they're called journals. And we have portals (or aggregators, or whatever you want to call them): they are things like PubMed. What we don't have is people putting things into the system in the first place. Growing a separate parallel system to do those things for lessons hasn't worked: as far as I can tell, most of what's uploaded to lesson repositories just sits there.

How Teaching Knowledge Is Transferred

Sun, 13 Sep 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I hesitate to say so, but I believe that we pedagogues tend to exaggerate greatly the amount of change in educational practice that results from reading what other people say should be done...

— Stephen Corey, 1951

Being back in Edinburgh thirty years on has occasioned much reflection upon lessons learned. This has occasioned a re-reading of some papers by Prof. Sally Fincher, whose research group at the University of Kent studies the teaching and learning of computer science. In particular, I have been looking at what they have discovered about how educators share teaching practices. I hope these excerpts and reflections are of interest. (Note: section titles link to papers.)

Experiences Adding a Lesson on Make

Thu, 20 Aug 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In June I added a lesson on Automation and Make. In this blog post, I describe how the lesson evolved, my experiences in porting it into the Software Carpentry lesson template, and the community's response...

Checking What We Teach

Fri, 14 Aug 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Back in May, Jonathan Klaasen wrote a post about setting up a lab data management system. After re-reading it, I think it's a good reality check on what we teach about databases: from what I can tell, we cover most of the information management needs that Jonathan touches on. I also think it could be a great motivating example for a lesson on databases, and on how to combine them with other tools like shell scripts. If you've ever built or used something like what Jonathan describes, I'd be grateful for comments describing where your setup is the same and where it's different.

Why I Am Not Excited About Julia

Thu, 18 Jun 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

If you hang out in scientific programming circles, you're probably heard of Julia by now. If you don't, or you haven't, it is:

Why We Can't Have Nice Things

Thu, 11 Jun 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In the beginning, there were tables: rows upon rows, with columns separated by commas or tabs or something more exotic. They were elegant but limited, so programmers said, "Let there be XML!" And lo, there came a great wailing and gnashing of teeth, for who among us can truly comprehend external (parsed) general entity declarations and the encoding thereof?

The Paradox of Learning Objects

Wed, 22 Apr 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Warren Code recently forwarded this post by David Wiley, a serial innovator in open education and educational reform. In it, he recapitulates the history of "learning objects" and the paradox at the core of the idea of remixing and reusing teaching material. Since Software Carpentry is (sort of) trying to do exactly that, I think everyone who's currently teaching for us or helping us meet our first publication deadline should look it over.

Learning in Both Directions

Tue, 21 Apr 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We have spent a lot of time thinking about how to assess the impact that Software Carpentry is having. We've done some small studies and collected a few testimonials, but it's been small potatoes compared to the 5000 people we taught last year alone.

After some back and forth with a colleague whose work I have admired for years, though, I realize that I've been trying to do this the wrong way. My training as an engineer taught me that only controlled, quantitative experiments were "real" science—that as Ernest Rutherford said, it's either physics or stamp collecting. I now understand that there are other rigorous ways to generate actionable insights, some of which are better suited to our needs than something like randomized control trials. More than that, I finally understand what one of my first teachers told me:

Teaching only works well when the teacher is also learning.

Quality Is Free - Getting There Isn't

Wed, 15 Apr 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Worried about the rising tide of retractions, Nature Biotechnology recently announced that, "Its peer reviewers will now be asked to assess the availability of documentation and algorithms used in computational analyses, not just the description of the work. The journal is also exploring whether peer reviewers can test complex code..." That's a welcome step in theory, but I worry about how it will play out in practice. Scientists already complain about how much time they spend reviewing papers: reviewing code as well will take even more time, particularly if:

Good Enough Practices in Scientific Computing

Mon, 13 Apr 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

April Wright recently wrote a blog post about the reproducibility of a paper she recently submitted. In it, she said:

A Project Inception Deck for Research Coding

Sat, 11 Apr 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I've never seen the point of comparing programmers to ninjas or samurai, but the people who do so often have good ideas. One that I particularly like is the Agile Inception Deck from Jonathan Rasmusson's The Agile Samurai, which sets out a ten-step process for making sure that everyone involved in a new project is actually trying to build the same thing. The ten steps are:

Nouns and Verbs

Mon, 02 Feb 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I've spoken and written many times about how puzzled I am that massive, open collaboration on lessons is so rare in the age of Wikipedia and open source software development. Hundreds of people have helped build the Wikipedia articles on Marvel Comics and the planet Mars, and hundreds more have helped build things like the Django web programming framework; why then are teachers still writing all their own slides and handouts?

As is frequently the case, the answer might be that I've been asking the wrong question. When I brought this up last week in an online call organized by the Open Knowledge Foundation, Phil Barker said:

"One difference between Wikipedia and OER [open educational resources] is that editing Wikipedia is about moving to consensus on facts, [but] editing teaching material is about tailoring it to specific local requirements (different teaching styles, different students, different curriculum standards)."

The Other Ninety Percent

Sat, 24 Jan 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Ninety percent or more of learning a skill takes place outside formal lessons as people try things out for themselves and turn attention into habit. This works best if a mentor is on hand to answer questions and provide feedback, but our workshop format doesn't lend itself to that: in most cases, our instructors are back on a plane (or back in their own lab) as soon as they're done teaching, so our learners have to make sense of what they've just been shown on their own. Based on follow-up discussions and Jory Schossau's work, here are things they stumble over in order of increasing pain:

Orwell, Dickens, and How We'll Know We're Done

Sat, 17 Jan 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I started working on a short capstone example last month to show learners how to get a badly-formatted reference list out of an Excel spreadsheet and into a relational database so that it would be easy to answer questions like, "Who has co-authored papers with whom?" I'd like to work up another capstone as well, but there's a problem: I can't actually do it myself for reasons that are both technical and political.

Language Wars and Others

Wed, 14 Jan 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We often get asked, "Why do you teach [X]? Why don't you teach [Y]?" where X and Y are random permutations of Perl, Python, R, MATLAB, Julia, C++, and Javascript, or equally random permutations of different version control systems or text editors. There are three answers:

The Future and Funding of Science

Sun, 04 Jan 2015 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I was talking with friends over the holiday about the future of science and how it might one day be funded. Since it'll be ten years before I'm proven wrong, it seems like a good topic with which to start the new year.

Why It Matters

Tue, 11 Nov 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Sometimes I forget that it isn't obvious why scientists ought to learn to program—or why anyone else ought to. Being more productive, getting a better job... Those are all good reasons, but as Bret Victor points out, if we focus on those, we risk losing sight of what matters most.

To explain that, I have to quote Matthew Crawford's thought-provoking (and sometimes infuriating) Shop Class as Soulcraft:

Why We Don't Teach Testing (Even Though We'd Like To)

Thu, 30 Oct 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

If you haven't been following Lorena Barba's course on numerical methods in Python, you should. It's a great example of how to use emerging tools to teach more effectively, and if we ever run Software Carpentry online again, we'll do it her way. Yesterday, though, when she posted this notebook, I tweeted, "Beautiful... but where are the unit tests?" In the wake of the discussion that followed, I'd like to explain why we no longer require people to teach testing as part of the Software Carpentry core, and then ask you all a favor.

Why Software Matters

Tue, 28 Oct 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Why does software matter to scientists? It may seem obvious to people who read this blog, but that's like saying that the answer to, "Why opera?" is obvious to the sort of person who pays a month's rent to get a decent seat at Covent Garden. Why does software matter? And why does it matter whether it's written well?

Lost in Space

Mon, 27 Oct 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

You probably haven't seen the 1998 movie Lost in Space, or if you have, you've suppressed the memory—it was awful. But I do know one guy who enjoyed it. His name was Joe, and he had worked on the software used to create its special effects. Ten minutes into the film he took out his Walkman (a primitive form of iPod), put on his headphones, and spent the next two hours head-bobbing to a mix of Bob Marley and Smashing Pumpkins.

Ideas to Improve Instructor Training

Sun, 05 Oct 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Have you ever learned something new and then had it appear in other areas of your life? After a summer at SWC thinking about how to train better instructors (and how to be a better teacher myself) I get to try discussion-based teaching this quarter at UC Davis.

Further Thoughts on Building Better Teachers

Wed, 10 Sep 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

On Greg's recommendation, I just finished reading Building a Better Teacher - it was an interesting book, and a well-written story. It turns out that I completely agree with Greg's assessment of the book's lessons and the challenges facing Software Carpentry, but I very much disagree with his proposed solutions!

More Thoughts on Better Teachers

Wed, 10 Sep 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Over the last few weeks I read Greg's blog post on Building Better Teachers and watched his Scipy keynote and I've been thinking a lot about how can instructors share their knowledge.

Building Better Teachers

Thu, 04 Sep 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Some books are intrinsically great. (I've read Going Postal half a dozen times, and enjoyed it just as much at each encounter.) Other books feel great because they hit you at the right time. Elizabeth Green's Building a Better Teacher is one of those: in a little over 300 pages, she takes a bunch of things I've been worrying about for the last two years and assembles them into a coherent whole. The end result is a road map of sorts for making our teaching more effective; the problem is, I don't know if it's a path we can actually follow.

The New MATLAB Teaching Materials

Fri, 29 Aug 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

When Software Carpentry started running bootcamps back in 2012, Python was used exclusively for the programming lessons. While these lessons were as language agnostic as possible (i.e. the materials focused on transferrable programming concepts as opposed to specifics of the Python language), people soon expressed an interest in running bootcamps using other languages. R very quickly established itself as a regular alternative to Python, but it wasn't until early 2014 that the first ever Matlab bootcamp was held (see here and here for blog posts about the event; the official event page is here).

Software Carpentry at Brazilian Open Science Conference

Sat, 23 Aug 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Last week, Raniere Silva and Alex Viana attended at Brazilian Open Science Conference where they ran a Git course for Software Carpentry and Alex gave a talk about Software Carpentry (like the one that Damien Irving gave at PyCon Australia). Our workshop was a great time and from the feedbacks every student like it. One of the students said:

Very didactic, the instructors showed much care, dedication and attention with the students.

and another one

Very good, from the basic to complex in a easy way.

Sustainability

Mon, 04 Aug 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I took part in a meeting about sustainable scientific software at last month's SciPy conference. Much of it was taken up with discussion of getting scientists recognition for building software, but there was also some interesting debate about what "sustainability" actually means. After talking to a few people in the software engineering research community, I'd like to propose that:

Using a Package Manager for Lessons and Papers

Mon, 21 Jul 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I've been musing for a couple of years now about ways in which we could re-purpose off-the-shelf software engineering tools and techniques to serve the needs of teachers. One theme, which I touched on in my SciPy 2014 talk, is to get people to patch shared learning materials in the way they patch Wikipedia articles and open source code. Another is to use package managers like RPM, Homebrew, and Conda to track dependencies between lessons, so that I could say something like conda install suffragette_movement and get a lesson on the struggle for women's voting rights, along with the other lessons and materials it depends on (or updates and links to those other lessons if I already have some of them installed).

Scientific Groupware Revisited

Sat, 05 Jul 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

16 years ago, Jon Udell wrote a white paper titled "Internet Groupware for Scientific Collaboration" that profoundly changed how I thought about the web. In many ways, it seems as futuristic today as it did then: despite all the technological advances of the last decade and a half, a two-way web built on top of a universal canvas is still mostly a dream.

Udell and others are now working on Thali, an attempt to create a truly distributed web. It, and projects like Ward Cunningham's Smallest Federated Wiki, are a more truly open model for science than the de facto centralization typified by Google, Facebook, Twitter, and GitHub, but it's not clear we'll choose the long-term robustness of the former over the short-term convenience of the latter.

I asked Jon if I could re-post IGSC here. He said yes, but on reflection, I realized that doing so would run counter to the spirit of what he's been trying to tell us. Instead, I urge you to click on this link and marvel at the everyday miracle that follows.

Knocking on the Future's Door

Thu, 08 May 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Once again I feel like I'm knocking on the future's door but nobody's answering. The task we set ourselves seemed simple: produce a nicely-formatted PDF of the Version 5 lessons to give learners as a reference (and to print as a book to give instructors when they finish their training). Fifty years after the creation of the first computer typesetting systems, you'd think this would be easy. It's not, and the reasons why highlight yet again why so many scientists would rather keep playing the kazoo than learn to play the violin.

Playing the Kazoo

Mon, 05 May 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Yesterday, Matt Davis quoted Peter Wang as saying, "A violin is to a kazoo as Python is to Excel." To which I replied, "Exactly: anyone who wants to make music can play a kazoo right away without days of training." The difference between these two points of view lies at the heart of Software Carpentry. As I said in a post two years ago:

Mr. Biczo Was Right

Wed, 23 Apr 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I didn't have nearly enough time to enjoy everything that was going on at PyCon 2014 last week. One event I particularly regret missing was a sprint organized in part by the folks at Scrapinghub. They got a bunch of people to write little scrapers to go through old conference websites, pull out speakers' names, and run them through a gender identification library in order to plot changes in gender balance per conference over time. The code is all available on GitHub, and Gayane Petrosyan (currently at the Hacker School in New York City) has started plotting some of the results.

Does Continuous Publication Require Continuous Attention?

Sat, 05 Apr 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I read this post by Martin Fenner a couple of weeks ago. His thesis is that scientific publication is still very much a manual process, which makes publications relatively infrequent (and fairly painful) events. Instead, we ought to strive for continuous delivery: production of the "paper" (including release of associated code and data) should be fully automated so that authors can ship whenever they want with relatively little effort.

Continuous delivery is popular among software developers, who frequently argue it's more efficient using diagrams like this:

Not on the Shelves

Sun, 23 Mar 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Every few years, I indulge in a bit of sympathetic magic by writing reviews of books that don't actually exist in the hope that it will inspire someone to write them. Previous versions written in 1997, 2003, and 2009 led to Beautiful Code, Making Software, The Architecture of Open Source Applications, and a few others books as well. I'd welcome comments on what isn't in this list that you really wish you could read.

What Tools Do You Use to Get Your Job Done?

Sun, 23 Mar 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Some of you may have heard of usesthis.com. In this site people are interviewed about the tools they use to get their job done. The format is very straight forward, participants have to answer these questions:

Everything Old is New Again

Fri, 14 Mar 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Yesterday, the New York Times R&D Lab announced streamtools, a web-based graphical tool for working with streams of data. It lets users create dataflow systems to re-mix and process the streams they believe most data will consist of in the near future.

Streamtools looks nice, but I do have some questions:

You and Jimi Hendrix

Fri, 14 Mar 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I had a discussion a couple of weeks ago about software development tools and processes with some undergraduate students I'm mentoring. They asked why I'm so finicky about putting things under version control, writing unit tests, and creating tickets to keep track of what still needs to be done. The short answer is, because that's what Jimi Hendrix would have done.

Anatole France, Updated

Fri, 07 Mar 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Anatole France (1844-1924)

Then

The law, in its majestic equality, forbids the rich and poor alike to sleep under bridges, to beg in the streets, and to steal bread.

Now

The Internet, in its majestic equality, allows every scientist to analyze massive data sets using web services and cloud computing.

Why Not a MOOC?

Sun, 19 Jan 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We got mail yesterday asking us whether we were going to run Software Carpentry as a MOOC. The short answer is, "No." The full answer has several parts:

Publishing on the Web

Wed, 15 Jan 2014 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Back in December, I asked a question on the Software Carpentry issue track: What should we teach about writing/publishing papers in a webby world? It led to a lively discussion about how the web is changing scientific publishing, the tools people can use to take advantage of those changes, and the gap between what's possible and what publishers (and senior academics) will actually accept. Many commenters dove immediately into the details of specific tools, but Justin Kitzes nailed it when he said:

Tools, Conversations, and Cultures

Tue, 31 Dec 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Philip Guo is best known these days for The Ph.D. Grind, but I first met him through his Online Python Tutor. He helped teach a bootcamp for librarians last August, and recently wrote a blog post about the two cultures of computing that he encountered there. On one side he sees users who treat software as a tool for getting things done; on the other, he sees programmers who hold conversations with their software. The former use stand-alone GUIs backed by binary file formats (like Word and Excel), while the latter use command-line interfaces and text (like the shell, LaTeX, and Python). He writes:

Catch and Hold

Fri, 27 Dec 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I'm a big fan of Mark Guzdial's work on computing education. Last week, he tweeted this:

Google is made of people who succeed in current CS teaching model. Hard for them to realize that it's wrong for most people. #GoogleCSFirst

The State of Open Science

Thu, 17 Oct 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

As part of the biannual Mozilla Summit a couple of weeks ago, John Jensen presented a report on the health of the open web. The details were fascinating, and are summed up in a graphic showing how the various layers of openness that we all depend on are doing. I've reproduced it on the left, and summarized my view of how open science is doing by those same measures on the right:

Open Web
User Choice & Control	Social Activity	Economic Activity	Trust
Diversity of Services
Innovation
Content Freedom
Interoperability
Access

Open Science
User Choice & Control	Social Activity	Economic Activity	Trust
Diversity of Services
Innovation
Content Freedom
Interoperability
Access

You Keep Using That Word

Thu, 17 Oct 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The first Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE) is going to be held in conjunction with Supercomputing 2013 on Sunday, November 17. After reading the papers on the workshop site, my reaction was:

The Future: Today

Fri, 27 Sep 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Two papers appeared on my radar this week that give a taste of the kind of science we want everyone to be able to do in five years' time. The first, by Aide et al, is "Real-time bioacoustics monitoring and automated species identification"; the second, by Omberg et al, is "Enabling transparent and collaborative computational analysis of 12 tumor types within The Cancer Genome Atlas". They're both excellent pieces of 21st Century science, and they caught my eye because:

They're open access: I was able to read them on the off chance that they'd be interesting.
They show how a few scientists with serious software skills can accelerate the research of hundreds of others, provided those others have a few skills themselves.

Two Cheers for GitHub

Fri, 23 Aug 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

There's been a micro-flurry of excitement in the scientific world about GitHub's recent announcement that they will now render tabular text files (i.e., CSV and TSV) on their site. Coming on the heels of their support for GeoJSON, this is still more evidence that they're serious about becoming a platform for working with data.

So why only two cheers? Because they're going about it in the wrong way, and as a consequence, they'll deliver a lot less value than they could, a lot later than they could.

Where We Are (More or Less)

Fri, 24 May 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In January 2012, John Cook posted this to his widely-read blog:

In a review of linear programming solvers from 1987 to 2002, Bob Bixby says that solvers benefited as much from algorithm improvements as from Moore's law: "Three orders of magnitude in machine speed and three orders of magnitude in algorithmic speed add up to six orders of magnitude in solving power. A model that might have taken a year to solve 10 years ago can now solve in less than 30 seconds."

Git vs. Subversion and Feedback in General

Fri, 10 May 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Software Carpentry's mission is to help scientists teach other scientists how to be better programmers. If we want to do that successfully, we need to be scientists ourselves. In particular, we need to base what we teach on evidence, not anecdotes or personal preferences.

For example: we taught Git at the Toronto bootcamp last week, and once again I think our learners would have absorbed more if we'd taught Subversion. Why? Well, take a look at this diagram by Oliver Steele (which I found on this page written by Nick Quaranto):

A Rational Computing Process: How and Why to Fake It

Thu, 02 May 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Parnas and Clement's 1986 paper "A Rational Design Process: How and Why to Fake It" [1] is one of the most widely read in the history of software engineering. In it, they argued that designing software according to some particular process isn't what matters; what does is creating documentation after the fact to make it look as though a rational process was followed so that other people can retrace the designers' thinking without heroic effort. Acknowledging the messiness of reality wasn't new: a century ago, Poincaré wrote that most mathematicians figured out the proof after they had figured out the answer, and everyone knows that the description of the experiment that's put in the paper is almost never how the experiment was actually done [2]:

Spreadsheets, Retractions, and Bias

Fri, 19 Apr 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Just in case there's any misunderstanding:

I'm not suggesting that scientists should use Excel.

Now, with that out of the way… Guy Deutscher's wonderful book Through the Language Glass devotes several pages to the Matses people of South America:

Their language…compels them to make distinctions of mind-blowing subtlety whenever they report events… [Verbs have] a system of distinctions that linguists call "evidentiality", and as it happens, the Matses system…is the most elaborate that has ever been reported… Whenever Matses speakers use a verb, they are obliged to specify—like the finickiest of lawyers—exactly how they came to know about the facts they are reporting… There are separate verbal forms depending on whether you are reporting direct experience (you saw someone passing by with your own eyes), something inferred from evidence (you saw footprints on the sand), conjecture (people always pass by at that time of day), or hearsay (your neighbor told you he had seen someone passing by). If a statement is reported with the incorrect evidentiality form, it is considered a lie.

I thought about this in the wake of reactions to two reports this week of errors in scientific work. The first was the discovery by Herndon and others of mistakes in Reinhart & Rogoff's widely-quoted analysis of the relationship between debt and growth—mistakes that were due in part to bugs in an Excel spreadsheet. Quite a few of the scientists I follow on Twitter and elsewhere responded by saying, "See? I told you scientists shouldn't use Excel!"

Correctness Isn't Compelling

Mon, 11 Feb 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The final report from the ICERM workshop on Reproducibility in Computational and Experimental Mathematics is now available, and its appearance has prompted me to explain why we don't put more emphasis on reproducibility in Software Carpentry. Long story short, it's because scientists don't care because they're not rewarded for doing so. Here's the math:

Assume five million scientific papers were published in the decade 1990–2000. (The actual number depends on what you include as a "paper", but our reasoning holds.)
Of those, perhaps a hundred have been retracted because of honest computational irreproducibility ("honest", because fraud isn't part of this argument).
That means the odds that a scientist will have to retract a particular paper because someone noticed that her calculations couldn't be reproduced are one in fifty thousand.
So if the average paper takes eight months to produce, and scientists work six-day weeks, that means it's only worth spending 115 extra seconds per paper on reproducibility as insurance.

Different assumptions and models will naturally produce different answers, but won't change the conclusion: given the system we have today, investing extra time to make work reproducible as insurance against error isn't economical. RR's advocates may respond, "That's why we're trying to change the system," but chicken-and-egg traps are notoriously difficult to break out of: if people don't care about the reproducibility of their own work, they're unlikely to check it when reviewing other people's work, and around and around we go. Trying to get them to be an early adopter of new practices (which aren't yet rewarded consistently by their peer group) is therefore a very hard sell.

Features and Scope in Open Courseware

Sun, 03 Feb 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A couple of weeks ago, Brian Granger (one of the core developers of IPython) posted some thoughts on features and scope in open source software. In it, he enumerates some of the risks associated with constantly adding new features to a piece of software (open source or otherwise):

Additional complexity in the code base (which makes future work more difficult).
Increased "surface area" for bugs (the more features there are, the more places a bug might be lurking).
Increased documentation and support time.
It forces developers to specialize, which makes "big picture" thinking harder.
Increased testing effort.
A more complex user experience. (Microsoft Word, anyone?)
Opportunity costs: time spent working on X is time not spent working on Y.

He then enumerates some things projects can do to throttle growth down to manageable levels:

The Missing Side of the Triangle

Sun, 03 Feb 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A few weeks ago, John Cook posted the following:

In a review of linear programming solvers from 1987 to 2002, Bob Bixby says that solvers benefited as much from algorithm improvements as from Moore's law.

Three orders of magnitude in machine speed and three orders of magnitude in algorithmic speed add up to six orders of magnitude in solving power. A model that might have taken a year to solve 10 years ago can now solve in less than 30 seconds.

Novelty, Efficiency, and Trust

Mon, 28 Jan 2013 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I've spent a lot of time trying to figure out what the "big picture" is for Software Carpentry. What are the best practices every scientist should master? What are the principles of computational thinking? How exactly are we helping people? My latest attempt to put this all in a nutshell has three strands: novelty, efficiency, and trust:

By improving scientists' computing skills, we're helping them do things they couldn't do before.

We're also showing them how to do things with less effort.

Finally, scientists can have more confidence in results (both their own and others') that are produced our way.

The second of these, efficiency, is what sets us apart from other "computing for scientists" initiatives. On on side, supercomputing and big data have opened up entirely new kinds of science, just as radio telescopes and PCR did. On another, advocates of open access and reproducible research are changing the way science is done, and by doing so, making it easier for people to check and build on each other's work. Our goal is to help them implement all of these things without superhuman effort—to do with ten minutes of scripting what used to take an hour of mousing around in a spreadsheet.

You've Shown Me the C, Now Where's the Python?

Sun, 16 Dec 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The W3C's Provenance Working Group recently published a new draft of their proposed standard for tracking provenance on the web. It's pretty dense stuff: even the primer, which uses the word "intuitive" five times to describe itself, is hard to follow if you've never been immersed in Dublin Core, TURTLE, and the like. That isn't a criticism—this stuff is intrinsically hard—but I think most scientists won't be able to see the forest for the trees.

Why Be an Instructor

Wed, 05 Dec 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Our instructors are all volunteers—bootcamp hosts cover their travel and accommodation costs, but they're not paid for their time. So why do they do it?

Make the world a better place. As I say in a lot of my talks, the two things we need to get through the next hundred years are more science and more courage. I don't know if we can do much about the latter, but we can sure help a lot with the former.

Make their own lives better. Most of the time, we try to have astronomers teach astronomers, ecologists teach ecologists, and so on. These are people whose tools instructors might one day want to use themselves, so by making them more clueful, instructors are helping themselves.

It's fun. How could it not be? You get to stand up and look smart in front of a bunch of smart people who actually want to be there, and you don't have to mark anything afterward.

Build a reputation. Showing up to run a really useful workshop is a great way for people to introduce themselves to places they'd eventually like to work, and a great way to make contact with potential collaborators. This is probably the most important reason from Software Carpentry's point of view, since it's what makes our model sustainable.

Get practice teaching. We're doing more every year to train instructors, and giving them chances to teach online as well—both of which are useful for people with academic careers in mind.

Help get people of diverse backgrounds into the pipeline. Computer Science is 12-15% female, and that figure has been dropping since the 1980s. From what I've seen, there's a similar gender skew among computationally-oriented people in other sciences, which if left alone will be self-perpetuating. Some of our instructors are involved in part because they want to break that cycle and be a public example of a competent, confident woman programmer.

Teaching forces you to learn new things, or learn old things in more detail than you already know. See for example "Graduate Students' Teaching Experiences Improve Their Methodological Research Skills"

The more you know, the less you have to write yourself. Putting a grant application together? Have a site review coming up? We probably have slides for that... :-)

And why do people do online office hours? For some, the primary incentive is a little bit of guilt: we can't give everyone all the help they need during a two-day workshop, and online follow-up is a way to make up for that. For others, it's a chance to pick up and practice some skills that are increasingly in demand: everyone believes that a lot of teaching is going to move online in the coming years, and this is a way to figure out how to do it.

Web 4 Science

Tue, 13 Nov 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Titus Brown (a long-time supporter of, and contributor to, this project) has a series of posts on his blog about using the web for science. As he's well ahead of the curve in doing this himself, I thought readers of this blog would be interested:

opening remarks

the awesomeness we're experiencing

the challenges ahead

strategizing for the future

tech wanted

There's lots here to chew on—I'm sure he'd welcome comments from our readers.

An Administrative Note

Mon, 05 Nov 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In order to maintain focus, I'm moving discussion of general education & technology issues over to my personal blog. I will continue posting items specifically related to teaching computational competence to scientists here.

Twenty Percent

Tue, 23 Oct 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I realized a couple of days ago that I'd never blogged about what Software Carpentry needs to accomplish in order to change the practice of science fundamentally and permanently. In a nutshell, we need to convert a fifth of scientists to our way of thinking. Once we do that, the odds are better than 50-50 that every time someone sends a paper out for review, at least one reviewer will ask hard questions about how the computational work was done. I get that number by assuming:

Rebuilding Redux

Fri, 12 Oct 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The time has come to replace our creaking combination of web tools with something that will let us do more for more people while spending less time switching between browser tabs. To recap an earlier post, we currently use:

WordPress for our blog, web site pages, and comments;

YouTube to host our videos (links to which are embedded in the WordPress pages);

Subversion (administered via the Dreamhost control panel) to manage our slides, code examples, and other files;

Mailman (administered the same way) to manage mailing lists;

a Google Map to show the locations of past and future bootcamps;

a Google Calendar to show their dates;

Google Analytics to track web site traffic;

EventBrite to handle event signup; and

OpenBadges to keep track of who's accomplished what (currently in beta).

We also use Vidyo for video conferencing (primarily tutorials), and run Etherpad beside it so that people have a text channel for asking questions, posting links and code fragments, taking minutes, and so on. As I pointed out in that aforementioned post, this means admins need at least six different logins to get things done, and need to copy a lot of information from place to place. For example, whenever we commit to a new bootcamp, someone needs to:

Dark Matter, Public Health, and Scientific Computing

Wed, 10 Oct 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

This is the text of a talk given at the 8th IEEE International Conference on eScience, October 10, 2012. The slides are also available.

Back in March, Scott Hanselman wrote a blog post titled Dark Matter Developers: The Unseen 99% that crystallized something I'd been thinking about for a while. In it, he said:

[We] hypothesize that there is another kind of developer than the ones we meet all the time. We call them Dark Matter Developers. They don't read a lot of blogs, they never write blogs, they don't go to user groups, they don't tweet or facebook, and you don't often see them at large conferences... [A]s one of the loud-online-pushing-things-forward 1%, I might think I need to find these Dark Matter Developers and explain to them how they need to get online! Join the community! Get a blog, start changing stuff, mix it up! But...those dark matter 99% have a lot to teach us about GETTING STUFF DONE... They aren't chasing the latest beta or pushing any limits, they are just producing.

Wanted: An Entry-Level Provenance Library

Thu, 04 Oct 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

One of the reason we keep teaching Subversion is that it allows us to show students a simple but useful trick. If you add the following to a text file:

$Revision: $

and then tell Subversion to set the "Revision" keyword on that file, the next time you commit it, Subversion will automatically update the text to:

$Revision: 423$

or whatever the revision number actually is. This is handy if you're mailing files around, and want people to be able to tell exactly which revision they have, but what makes it really useful is this:

The Real Hard Work

Sun, 30 Sep 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I spent a couple of thought-provoking hours at Codecademy's office in New York on Thursday, during which my host said, "It's so different from Silicon Valley, where a lack of experience is considered an asset." The next day, while teaching at Columbia, I used one of my favorite sayings, "A week of hard work can sometimes save you an hour of thought," and someone in the audience piped up, "Or an hour of reading." The two comments helped crystallize something that I've been thinking about for several months now about what's hard for creative people to do, and what implications that has.

Not Really Disjoint

Tue, 04 Sep 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The twinned discussions in bioinformatics about openness and software quality are heating up. A recent salvo on Gas Stations Without Pumps is titled "Accountable research software", and one statement in particular caught my eye:

The rapid prototyping skills needed for research programming and the careful specification, error checking, and testing needed for software engineering are almost completely disjoint.

I might agree that careful specification isn't needed for research programming, but error checking and testing definitely are. In fact, if we've learned anything from the agile movement in the last 15 years, it's that the more improvisatory your development process is, the more important careful craftsmanship is as well—unless, of course, you don't care whether your programs are producing correct answers or not.

Lifted by the Audience

Sun, 02 Sep 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I spent Thursday and Friday recording most of the material we've been using in workshops for the past six months [1]. One thing that kept bugging me was how flat and uninspiring it was to talk to a camera: I had forgotten just how much a live audience energizes me. I also realized how much I rely on people's questions, and the expressions on their faces, to keep me on track: it took me almost 15 minutes to remember that I needed to explain that Python uses indentation to show nesting, whereas I always do that at the right time in a live class because someone either asks or looks puzzled.

How Robust Is Your Programming Language?

Sat, 21 Jul 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

One of the biggest problems in teaching novices how to program is that most programming systems are not robust. A car can go quite a long distance on a slightly-flat tire, and people can live for years with just one kidney or half a liver, but get one character out of place in a program, and boof—it's game over. And spotting that one character can be very hard, particularly if you're a novice and are learning mostly through copy-paste-and-tweak.

Pessimism and Doom

Tue, 26 Jun 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

According to recent research, an absence of optimism plays a large role in keeping people trapped in poverty:

This hopelessness manifests itself in many ways. One is a sort of pathological conservatism, where people forgo even feasible things with potentially large benefits for fear of losing the little they already possess.

The parallels with scientific computing practically jump off the page, don't they?

If You Want to Teach, Isn't It Only Fair to Learn a Few Things First?

Mon, 25 Jun 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Carla, a high school student, is doing a class project comparing climate change in the Northern and Southern hemispheres. She wants to see whether the gap between the average annual temperatures in Canada and Australia increased during the Twentieth Century. The raw data she needs is available online; all she needs to do (for some value of "all") is get it, load it into her program, do her calculations, and create an HTML to display her results for other students to see.

But the Greatest of These Is...

Fri, 08 Jun 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In her EAGE keynote earlier today, Victoria Stodden talked about the central role of geophysics in the reproducible research movement. After discussing the problem, she identified five interlocking solutions:

Tools

Intellectual property barriers

Funding agency policy / federal regulation

Journal policy

Institutional expectations

I think these are all important, but I think they are all less important than something which doesn't appear anywhere in her slides:

Alone and Misunderstood

Wed, 23 May 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Jeffrey Mirel and Simona Goldin's recent article in The Atlantic titled "Alone in the Classroom" initially struck a chord with me, particularly when they said, "A recent study by Scholastic and the Gates Foundation found that teachers spend only about 3 percent of their teaching day collaborating with colleagues. The majority of American teachers plan, teach, and examine their practice alone." But then Mirel and Goldin blew it by saying:

Responsible Conduct

Wed, 23 May 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Titus Brown, Ethan White, and I have been talking about what Responsible Conduct of Research (RCR) standards would look like in computational science. Titus has posted a four-point summary; we would welcome your input over on his blog.

Citing Versions

Tue, 22 May 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We got mail yesterday from a workshop participant saying, "My question is how does one show in a research paper that the underlying data and the software is version controlled?" Cameron Neylon's answer, slightly edited, was:

My approach in an idea world would be to have all of my data (or links to it) under version control along with the code. When the version to be used for the publication is clear I would give it a tag (I'm a Git user but there is similarly functionality in all version control systems) and then push that to an online repository. You can then give a link or reference to the appropriate repository version online. If you don't want to put your main repository online then you could just put up the version from the publication.

What's Wrong With All This?

Sun, 20 May 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Titus Brown doesn't like this web site. He's OK with the content (I think), but he finds it awkward to use, and while I don't feel as strongly as he does, I accept that we have outgrown WordPress. The question is, what should we use instead? We need a lot more than just a blog and some static web pages, but learning management systems like Moodle weren't built with our ad hoc model in mind (they're really teaching administration systems), and newer tools like P2PU feel like a step backward. I started thinking about requirements for a replacement back in April, but got distracted. Here's a longer look.

Better Across the Pond?

Mon, 30 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I'm sitting in a packed room helping out at the UCL bootcamp, the first of a series to be run in the United Kingdom (Newcastle is next, and there are plans to run additional workshops in Oxford, RAL, Glasgow, Edinburgh and Bristol). I'm thinking about two things: why would you design a 60 seater lecture theatre with only one window for ventilation and why is Software Carpentry so popular in the UK?

Stop Me If You've Heard This One

Sat, 28 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I used to tell this joke:

An engineer says, "Theory approximates reality."
A mathematician says, "Reality approximates theory."
A sociologist says, "Would you like fries with that?"

Skip forward ten years. It was the early 2000s, just after the first dot-com bubble burst, and I started noticing that all of a sudden, programmers were taking design and graphic designers seriously. Overnight, it seemed, companies had started paying designers competitively and giving them real authority. Somehow, nerds like me who had made jokes about people with "soft" skills (and boy, isn't that term revealing) had come to realize just how valuable and difficult those skills were.

Behind the Scenes (or, the Ethics of Cultivating Discontent)

Wed, 18 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A lot goes on behind the scenes here at software-carpentry.org:

The site itself is WordPress with a partly-customized theme. We use the blog for topics like this and pages (over a hundred of them) for lecture topics. We used to use Trac to manage work items, but nobody kept it up-to-date; these days, we use a WordPress to-do list plugin for the same purpose, and with as little result.

Our videos are hosted on YouTube—we used to store them locally, but performance improved a lot when we offloaded.

We manage our mailing lists and version control repositories through the Dreamhost control panel, which actually delegates mailing list management to Mailman.

The calendar and map are hosted by Google.

We do event registration through EventBrite.

We currently use BlueJeans and Skype for web conferencing, but it's been plagued with both technical and social difficulties: people need to have the right Skype client for their OS, and there are the usual problems with unmuted microphones, unintelligible audio, feedback loops, and so on. Forget flying cars: I'll believe the future has arrived when we can make this work...

This analysis leaves me feeling a bit conflicted. When I think about what we should teach researchers about the web, I have three requirements:

GitHub for Education

Tue, 17 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In my experience, most teachers don't develop courses from scratch. Instead, they take whatever material is at hand, modify it to meet their needs, and then—well, that's usually where they stop. Unlike open source software developers, they usually don't give it back to the community in any explicit way. Instead, the next person who needs a starting point has to stumble over it in a Google search, and the original creator may never know that someone improved upon what they did.

In Search of Prior Arguments

Tue, 17 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A faculty member whose research involves building some fairly complex scientific software would like to make all his work open source. He is repeatedly having to justify this choice to funding agencies and his dean, whose objections include:

concern for sensitive information being released (anything involving pollution has the potential to become a political football)

concern for misuse by naive users undermining the reputation of the tool

concern for missing value in licensing the IP

I know lots of other people have had to overcome these and other objections; what I'm looking for is a published (and preferably peer-reviewed) refutation of them that he and others can cite, preferably one that is specific to open source in science (rather than in general). Pointers would be very welcome.

We're Neutral (but Not Really)

Sat, 14 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

From Wikipedia:

Open science is the umbrella term of the movement to make scientific research, data and dissemination accessible to all levels of an inquiring society, amateur or professional. It encompasses practices such as publishing open research, campaigning for open access, encouraging scientists to practice open notebook science, and generally making it easier to publish and communicate scientific knowledge.

The term reproducible research...refers to the idea that the ultimate product of research is the paper along with the full computational environment used to produce the results in the paper such as the code, data, etc. necessary for reproduction of the results and building upon the research.

On Crossing Australia (or, Further Thoughts on What to Teach Researchers about the Web)

Fri, 06 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A while back, I blogged about Bret Victor's "Inventing on Principle" talk at CUSEC'12, which is an inspiring vision of what programming could be. Ned Gulley's thoughts on it are more nuanced (and more interesting):

Victor's real power is his ability to rapidly create and deploy these tools. In a twinkling he can size up a task that is worth studying, put a box around it and spin a tool. He does this so effortlessly, with such mesmerizing legerdemain, that we lose sight of this meta-skill. What Victor was really doing in his talk was illustrating the power of tool spinning, the rapid creation of customized, context-sensitive, insight-generating tools...

Sending Email Back in Time

Sun, 01 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We're about to release the second volume of The Architecture of Open Source Applications, which has indirectly prompted a bit of soul-searching on my part. When we invited people to contribute, we asked them to give us the one-hour whiteboard talk they'd give to a new developer being brought onto the project. We also asked them to sum up what they'd learned. "Imagine you could send a brief email back in time," we told them. "What would you say to your younger self?" Which of course begs the question, what would I tell the me of 2010 about Software Carpentry?

What to Teach Researchers About the Web

Sun, 01 Apr 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

One reason I'm reflecting on what I've learned in the last two years is a question that is back on the top of my work pile: what should we teach researchers about the web? Partly, it's a priority because I'm currently embedded in Mozilla; their mandate is to defend and extend the open web, and their educational efforts are all aimed at that, so I ought to be doing something too. The real reason, though, is that a lot of things have brought this into sharper focus recently:

The Dark Matter of Computational Science

Sun, 18 Mar 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Scott Hanselman's recent post "Dark Matter Developers" got me thinking once again about what Software Carpentry is about. He says:

[We] hypothesize that there is another kind of developer than the ones we meet all the time. We call them Dark Matter Developers. They don't read a lot of blogs, they never write blogs, they don't go to user groups, they don't tweet or facebook, and you don't often see them at large conferences... Where are [they]? Probably getting work done.

What's the Model, Kenneth?

Fri, 09 Mar 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Over on rwxweb [1], Michelle Levesque has posted and dissected a diagram showing how various webbish skills depend on one another. It's an invaluable design aid, but it violates the third of Jon Udell's seven principles: it's presented as a bitmapped image, rather than as something a machine can easily parse and digest. I can't, for example, read the source and generate a two-column table showing "X depends on Y", or something like that. I wrote a bit back in January about what sort of data model we could use to represent things like that, but that's the wrong approach as well. What I really want is to discover that someone has already thought this through and created such a model, so that if I want to alter or extend Michelle's model, I can change the authoritative machine-readable representation [2], and she can merge (or at least diff) those changes. All I've found so far, though, are bits of database schema buried in things like Moodle and SCORM; there doesn't seem to be anything that a programmer would recognize as a model or format per se.

Reproducibility Redux

Tue, 28 Feb 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A recent editorial in Nature, and a longer article by Darrell Ince, Les Hatton, and John Graham-Cumming titled "The case for open computer programs", are just two signs of the growing pressure to raise standards around computational work in science. We can debate the exact meaning and value of reproducibility, but there's no arguing with the fact that if scientists want to do better work, they'll need better skills. That's the real long-term goal of Software Carpentry.

Granules of Research

Wed, 22 Feb 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Cameron Neylon recently posted an article titled "Github for science? Shouldn't we perhaps build TCP/IP first?" His argument is that the web's a good way to move text around, because it was built by programmers, and programmers work with text. It's not (yet) well suited to moving science around, because we don't (yet) have something as granular and portable as text for scientific ideas. Yes, any particular piece of research can be represented as text, but so can any image, or any audio stream, or anything else—it's the structure that adds meaning, and we haven't (yet) agreed on structures. Circling back to today's first post, part of what we're trying to do is give scientists the background to understand and take part in conversations like these...

Why *Not* Use Python

Tue, 21 Feb 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

When we started Software Carpentry back in the late 1990s, we used Perl as a teaching language instead of Python. At the time, it was a no-brainer: Perl had many more users, better documentation, and more libraries. We switched because we found ourselves explaining the same inconsistencies over and over again (as I've said many times since, every page of the O'Reilly Pocket Guide to Perl used one of the words "except", "unless", or "however" at least once). Python had fewer "buts": we saw right away that students were learning concepts more quickly, and they seemed to retain more as well.

How Many Legs Does Science Have?

Mon, 13 Feb 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Back in 2010, Moshe Vardi wrote an opinion piece titled "Science Has Only Two Legs", in which he argued that computational science is just another form of experimental science, and that programs should be held to the same standards as other pieces of experimental apparatus. It's an interesting counterpoint to recent excitement around "big data" (as evidenced in works like The Fourth Paradigm), and, I think, directly relevant to what we're trying to teach. What are your views?

Why We Don't Teach Parallel Computing in Software Carpentry

Tue, 07 Feb 2012 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Konrad Hinsen recently wrote a blog post that explains why teaching parallel computing with Python is hard. To make a long story short, Python's multiprocessing module can fail on simple problems in a whole bunch of ways that require fairly advanced understanding to diagnose and repair—and that's even before you try doing things on Windows.

It Just Keeps On Hurting

Tue, 20 Dec 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I received email a few days ago from someone who had just found this site (reproduced here with permission):

I am working on getting myself set up to do scientific programming in Python on a MacBook Pro. I plan to use mySql and Pentaho. I am new to open source, Mac, and Python. Where I've run into the most problems is getting a working environment established with all the tools in place. For instance, I ran into a huge problem trying to install mysqldb, the Python/MySQL interface package. Trying to resolve that, I've encountered a bewildering array of alternative ways to do things, each accompanied by strong opinions and each entailing a different group of packages. One example being package managers: easy_install, pip, various brews, macports, etc. I don't really care about some absolute right way—I just need working, consistent tool set.

Three Short Thoughts

Tue, 29 Nov 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A BBC article title "Coding — the New Latin" resonated: Latin was the language of learned discourse in the formative years of modern science, but not something most people spoke day-to-day. I think that's a good model for computing in the sciences; like statistics, it requires familiarity, not expertise.

Jorge Aranda's review of Codermetrics talks about the limitations to quantification in software engineering. I've said before that we need to measure how much time is lost due to poor computing skills in order to get people to take this kind of training seriously, but I'm very conscious of just how much measurement can't tell us.

Another thought-provoking post by Cameron Neylon asks what it's reasonable to expect from scientists, and their software. I'm sure he'd enjoy hearing what you think...

Accessible to All?

Fri, 18 Nov 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I just posted an article on my personal blog about the (in)accessibility of online educational material (including Software Carpentry's). As I said there, there aren't any easy answers, but if we do find funding to keep this project going, I'd like to find ways to make our content easier for everyone to use.

Quantifying Installation Costs

Fri, 18 Nov 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A few months ago, I tried to quantify the cost of poor software skills. A recent post from Adam Klein gives is a good excuse to try to do something similar for the cost of installing software. In his post, Klein describes the 17 steps he went through to set up a Python data hacking environment on a new machine. If we assume that each step has a 5% chance of failing for some reason (packages have moved on, the compiler isn't exactly the same version as Klein was using, whatever), then the chances of the whole process working are (1-.05)¹⁷, or roughly 42%. In other words, his process will fail to work the first time for over half of the people who try it. In some cases, they'll be able to figure out why, fix the problem, and move on, but in many others they won't—as I said earlier this week on my personal blog, we've taken something that may or may not be intrinsically hard (programming), and made it much harder by burying under layer upon layer of grief. The end result is that when a scientist sits down to try something new, s/he has no way of knowing whether it will take an hour, a day, or forever. It's hard to build a career on top of that kind of uncertainty...

Show Me the Data

Fri, 18 Nov 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I got mail from a colleague at a prominent US university yesterday saying (in part, and elided to protect the guilty):

...the graduate student representative to the curriculum committee reported that the students did not want a scientific computing course, that they would instead figure it out themselves.... How does one respond to statements like this...that have...basically frozen skill levels? The options I see are formal ("in curriculum") training, bootcamps and /workshops, and letting them "figure it out themselves". Are there arguments about the successes of each?

Clearing Up Code

Mon, 14 Nov 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The November/December 2011 issue of IEEE Software has a good article by the Climate Code Foundation's Nick Barnes and David Jones titled "Clear Climate Code: Rewriting Legacy Science Software for Clarity". In it, they describe how and why they rewrote a program used to calculate and compare global surface temperatures based on historical data. The original had been attacked by climate change denialists, first because it wasn't publicly available, and then because it was tangled and hard to run. Their rewrite produced something smaller, faster, and much easier to understand; most importantly, though, it validated the results of the initial program.

The Ladder of Abstraction and the Future of Online Teaching

Tue, 08 Nov 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Up and Down the Ladder of Abstraction is one of the most thought-provoking things to hit the web in a long time. Its author, Bret Victor, doesn't just talk about the design process—he shows us what a great interactive tutorial ought to look like. (For a shorter, simpler, but equally inspiring example, have a look at the home page for his Tangle project, and ask yourself what learning would be like if learners could play with every diagram and quantitative statement in their "textbooks" that way...)

Research Without Walls

Sat, 22 Oct 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Open science, reproducible research, and better computational skills aren't necessarily connected, but in my experience, people who care about one usually care about the others as well. In that light, I just signed the "Research Without Walls" pledge: effective today,I will assist in the peer review process (as a reviewer, board/committee member, chair, editor, etc.) only for conferences, journals, and other publication venues that make all accepted publications available to the public for free via the web. If you believe that sharing ideas is the heart and soul of science, please sign up as well.

Plus Ca Change...

Thu, 22 Sep 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Once again, Compute Canada has sent out a document for "review" without leaving time for people to provide meaningful input. And once again, it's all about "big iron", as if scientists were somehow, magically, going to acquire the basic skills needed to write modular code, test it, maintain it, and—oh, what's the use? I've known for years that the only way we're going to fix this is to show a younger generation of scientists that doing things the right way also makes them more productive, and then wait for them to have enough seniority to fix our backward-looking institutions.

Where is the Puck Going to Be?

Mon, 05 Sep 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Looking at the schedule for Science Online London 2011 makes me feel that Software Carpentry is showing people how to solve yesterday's computational problems—that it's answering the questions people had (or should have had) in 1995, when desktop applications were the only game in town, and when computers were primarily used for calculating, rather than for sharing. They still are, and I think that version control and regular expressions and what-not are still the rock on which more novel things are built, but a lot of other things are taking shape in the fog. You can call it "open science" or "science 2.0" or whatever you want, but its focus is on sharing information more effectively by changing publication models, enabling reproducibility, making data findable, encouraging scientists to use groupware (sorry—we're supposed to call it "social media" these days), and so on.

Doing the Math

Mon, 20 Jun 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Let's do some math. Suppose that working through the Software Carpentry course takes the average scientist five full-time weeks. It doesn't matter whether that's one five-week marathon, or whether the time is spread out over several months; the cost is still roughly 10% of the scientist's annual salary (if you're thinking like an administrator) or 10% of their annual published output (if you're thinking like the scientist herself). How big a difference does it have to make to her productivity to be worthwhile?

Practical Computing for Everyone (not just biologists)

Tue, 07 Jun 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Steven Haddock and Casey Dunn:
Practical Computing for Biologists.
Sinauer Associates, 2010, 0878933913.

My copy of Practical Computing for Biologists arrived last week, and I've been very impressed. It is a well-written, well-paced guide to basic computing skills for scientists and engineers of all stripes (not just biologists). Many of the topics will be familiar:

editing text files (including how to use regular expressions in an editor)

the Unix shell

basic Python programming (including debugging strategies)

relational databases

SSH

installing and configuring software

There are also a few that we don't cover, such as interacting with hardware, and some that are covered in more depth than we give them, like image manipulation. The pace is gentler than Software Carpentry, but the last couple of years have convinced me that's a good thing: I think Haddock & Dunn have it right for this target audience. And it's beautifully produced: full-color printing and great graphical design make this book a joy to read. If I ever do turn Software Carpentry into a book, I might skip the topics PCB covers and just tell people to go and buy it.

Harder Than It Should Be

Thu, 31 Mar 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Someone once said, "Chemistry is basically anything chemists will give each other awards for doing." Or something like that—Google doesn't find matches for that exact quote. Even if I've mangled it, the idea is sound: art is no more and no less than what great artists accept as being art.

So what is computer science? More particularly, what constitutes the core of computer science? What's the stuff that everyone who calls themselves a "computer scientist" should know, or at least have seen? One way to answer the question would be to look at what people are given prizes for, but that's turning out to be harder than I expected, and the reason highlights a gap in this course.

I'd Settle for 0.1%

Tue, 22 Mar 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

In a recent article about computational thinking, Carnegie-Mellon's Jeannette Wing says:

...every scientific directorate and office at the National Science Foundation participates in the Cyber-enabled Discovery and Innovation, or CDI, program, an initiative started four years ago with a fiscal year 2011 budget request of $100 million. CDI is in a nutshell "computational thinking for science and engineering."

0.1% of that would keep Software Carpentry going for another year... Or if I'm allowed to be a curmudgeon for a moment, hands up those people who believe that $100 million is going to do 1000 times more for science and engineering than another year of work on these materials? *sigh*

Graph Layout, Models vs. Views, and Computational Thinking

Wed, 16 Mar 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Money for me to keep working full-time on Software Carpentry hasn't materialized, so as I've mentioned in a couple of recent posts, I'm trying to find a way to organize the course material more coherently in the hope that other people will (finally) start to contribute content as well. As part of that, I have spent the last two days trying to draw a graph showing the questions Software Carpentry seeks to answer, and the concepts that underpin the answers. It's been harder than I expected, and I think the reasons might give some insight into how a computational thinker thinks.

Literate Programming

Mon, 07 Mar 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Last week's post about the tuple space programming model was so popular that I thought readers might enjoy a discussion of another beautiful idea that failed: literate programming. Like Lisp and other toenail-based languages, it inspires a kind of passion in its fans that is normally reserved for gods, sports teams, and angsty rock bands. And, like them, it leaves everyone else wondering what the big deal is.

Tuple Spaces (or, Good Ideas Don't Always Win)

Tue, 01 Mar 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I've resisted adding a module on high-performance computing to this course for a lot of reasons: I think other things are more important, there's enough coverage elsewhere, the software is hard for novices to set up... But there's another reason, one that may not be as good, but still has a seat at the table. Deep down, the reason I'm reluctant to teach MPI (the de facto standard for parallel programming) is that there's a much better model out there, one that works on all kinds of hardware, is comprehensible to novices, and delivers good performance on a wide range of problems. Its name is tuple space, its most famous implementation is Linda, and unfortunately, for a lot of reasons that I still don't understand, it somehow became an "also ran" in parallel programming.

Top Ten Why Nots

Tue, 15 Feb 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We've had quite a few firsts and successes in the past ten months, but our biggest failure continues to be the lack of contributions from users and educators: while quite a few people are using our material, only one person has (so far) volunteered to create material for us. If that doesn't change, Software Carpentry will stagnate as soon as I have to move on to other things (which, given my lack of success in raising another round of funding, will probably happen this spring).

Three Months, Two Spikes, One Conclusion

Wed, 02 Feb 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Here are the traffic stats for the last three months at software-carpentry.org:

November 2010

December 2010

January 2011

It's hard to make out what's happening because of the big spike in December, and the less prominent (but still significant) spike in November, so here's a summary:

Once these spikes are removed, the average number of distinct visitors is slowly increasing each month.

Posting a lecture on something popular boosts our readership dramatically, but only briefly, and only for that topic—most of those visitors don't stick around.

So what were the spikes? The first, in November, came when we posted our Python lectures. The second, in December, was Tommy Guy's episode on how to build a simple recommendation engine, which in turn was based on an example from Toby Segaran's excellent book Programming Collective Intelligence. That was more popular than anything else we've ever put on the site, which is both encouraging (if we build it, you will come) and disheartening (I have no idea what else to build that will be that popular).

The Case Against Peer Review

Wed, 26 Jan 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Cameron Neylon recently made the case against peer review once again; the dialog near his posting's end is too accurate to be funny. In this light, calls for peer review of scientific software are probably misplaced; we need a better mechanism than one that's already mostly failing.

Thinking Like the Web

Wed, 26 Jan 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Jon Udell's 1999 book Practical Internet Groupware was a revelation for me: it was the first coherent explanation I'd ever read of how the disparate collection of technologies and social conventions that we call "the web" fit together, and what the deeper patterns and concepts beneath them are. After a lot of further work and thought, Jon has condensed those ideas into seven principles—or as he puts it, "Seven Ways to Think Like the Web". These concepts are the most meaningful definition yet of what the phrase "computational thinking" actually means, and of what people who aren't programmers need to know in order to use the web effectively. As I said in the post on Tom Limoncelli's plea to software vendors, we'll know we're teaching the right things, the right way, when people who have done this course understand these principles and how to apply them.

Scientists Aren't Stupid: Software Is

Fri, 21 Jan 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Last night, Mike Bayer (@zzzeek) tweeted:

Why are "scientists", who are so dramatically smarter than me, such dumdums when it comes to basic programming skills: http://bit.ly/fWPtjW

Taavi Burns (@jaaaarel) replied:

Ask @gvwilson of @swcarpentry?

So here I am, and what I want to say is:

Scientists aren't stupid: software is.

Seriously. I spent an hour and a half last night trying and failing to get Thunderbird and Dreamhost's email to play nicely together. Today, I'm wrestling with the fact that Python's multiprocessing library gets lost in infinite recursion if you try to do something crazy like, oh, I don't know, leave out the if __name__ == '__main__' check (but only on Windows). In both cases, the parties involved can explain why it does what it does, and in both cases, I just... don't... care.

Making System Administrators' Lives Easier

Wed, 19 Jan 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Google's Thomas Limoncelli (author of Time Management for System Administrators) has an article in ACM Queue titled "A Plea to Software Vendors from Sysadmins—10 Do's and Don'ts". His list is:

Do have a "silent install" option.

Don't make the administrative interface a GUI.

Do create an API so that the system can be remotely administered.

Do have a configuration file that is an ASCII file, not a binary blob.

Do include a clearly defined method to restore all user data, a single user's data, and individual items.

Do instrument the system so that we can monitor more than just, "Is it up or down?"

Do tell us about security issues.

Do use the built-in system logging mechanism.

Don't scribble all over the disk.

Do publish documentation electronically on your Web site.

Every one of these applies equally to scientific software, big and small. We'll know we're teaching the right things, the right way, when people who have done this course know how to write software that obeys these rules and (more importantly) understands why they should.

Software Carpentry in One Picture and Five Words

Mon, 10 Jan 2011 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

This 1995 Pirelli ad pretty much sums up what Software Carpentry is about:

Compute Canada's 'Strategic' Plan Isn't

Tue, 21 Dec 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Last Friday—December 17—I received an email from Compute Canada. The emphasis is mine:

A Strategic Plan for Compute Canada was a key recommendation of the International Review Panel. This plan draws on suggestions from that panel as well as the information and discussions from the Town Hall Meetings held earlier this year. It has been many months in preparation and review by Compute Canada's committees and must be submitted to CFI before the end of December 2010... Your comments are invited and should be sent...by end of day Monday, December 20th.

Ratios and Rework

Tue, 16 Nov 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

It's been six months and a bit since we started working on Version 4 of this course, so I'd like to share two things we've learned about creating online tutorial videos:

It takes a long time.

A lot of that time feels like it should be unnecessary.

Let's start with "a long time". It takes me 3-5 hours to prepare a good slide deck for an hour-long lecture that I'm going to deliver in person. A slide deck for a screencast takes 8-10, because I need to prepare more slides: since there isn't a lecturer making eye contact and pointing at things to keep viewers engaged, a slide deck for online use has to have many more small transitions.

Five Rules for Computational Scientists

Thu, 14 Oct 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Stepping back from the details for a moment, here are five rules every computational scientist should (try to) follow:

1. Version Control

Put every primary artifact (source code, raw data files, parameters, etc.) in a version control system so that you have a record of exactly what you did, and when. There's no need to store things you re-create, such as the graphs you generate from your data files, as long as you have the raw material archived and timestamped.

Will America's Universities Go The Way Of Its Car Companies?

Mon, 13 Sep 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Two days before I flew south to speak at Michigan State University, I read an article in The Economist that asked the question in the title of this post. As it says (quoting US News & World Report), "If colleges were businesses, they would be ripe for hostile takeovers, complete with serious cost-cutting and painful reorganisations." I agree with many of their points: the universities I have worked at (six of them, on three continents) all suffered from the sedimentary buildup of red tape that you'd expect of a large organization that hasn't faced real competitive pressure in living memory, and struggled to achieve either of their core goals of fostering research and passing knowledge on. To quote a friend who's still in the system, "We're here to do research, they pay us to teach, we spend our time on administration."

An Answer That Most Students Won't Understand

Thu, 05 Aug 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Two days ago, I asked how to generates tests from tables of fixtures using Nose:

...does Nose already have a tool for running through a table of fixtures and expected results? My hand-rolled version is:

Tests = ( # R1 R2 Expected ( ((0, 0), (0, 0)), ((0, 0), (0, 0)), None ), ( ((0, 0), (0, 0)), ((0, 0), (1, 1)), None ), ( ((0, 0), (1, 1)), ((0, 0), (1, 1)), ((0, 0), (1, 1)) ), ( ((0, 3), (2, 5)), ((1, 0), (2, 4)), ((1, 3), (2, 4)) ) ) def test_table(): for (R1, R2, expected) in Tests: yield run_it, R1, R2, expected def run_it(R1, R2, expected): assert overlap(R1, R2) == expected

which is simple enough if students already understand generators and function application, but hell to explain if they don't—and they won't.

Open Source, Open Science in 1999

Tue, 03 Aug 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A long time ago, in a galaxy far, far away... Actually, it was 1999, and the venue was Brookhaven National Laboratory in New York—it just feels like a different time and place. The event was a conference called "Open Source, Open Science", and Stephen Adler, Tom Throwe, and Sean McCorkle have very kindly resurrected its web site at http://openscience.bnl.gov/ for those interested in the history of an idea whose time may finally have come. It's interesting to see what has changed in the intervening decade, and what hasn't: supercomputing is still disproportionately represented, but I think the open side has won the debate that was the subject of the main panel discussion, "Overcoming the obstacles...in using and contributing to Open Source technologies."

Mark Guzdial on Software Carpentry

Wed, 28 Jul 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Mark Guzdial, a leading researcher in computing education, blogged a few days ago about the Texas Advanced Computing Center's training program for computational scientists, and asked, "Given the importance of computational science, what do all scientists and engineers need to know about high-performance computing?" As you might expect, I replied to say that the question was almost always premature: we should first ask what scientists and engineers need to know about computing in general before tackling HPC.

A Note on Tools

Tue, 20 Jul 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

After a bit of experimenting, I've decided to use SmartSVN as a GUI client for Subversion in the version control lectures, rather than RapidSVN or the command line. My reasoning is:

Requiring people to learn the shell before they can start learning stuff they actually care about raises the drop-out rate noticeably. Requiring them to learn the shell before they can start learning something they don't yet realize they ought to use, like version control, raises it even more. That rules out the Subversion command line tools.

SmartSVN is dual-op (the stripped-down version is free, the pro version is not, neither is open source). In contrast, RapidSVN is pure open source, so it would be my first choice (in fact, it was)...

...except RapidSVN doesn't have a built-in diff/merge tool. They recommend SourceGear's DiffMerge, which is free (that's good) but users have to configure RapidSVN to use it (that's bad—very bad). On the Mac, for example, users have to copy a shell script into /usr/bin, then go into RapidSVN's preferences, set the path to the shell script, and get eight (!) command-line arguments exactly right, or things will fail in strange ways (like you can merge files, but when it tries to save your work, it doubles the dirname of the path to the file and then complains about not being able to create /Users/swc/repo/Users/swc/repo/filename).

If something can break for reasons that its intended users won't be able to understand, diagnose, and fix, then that something is itself fundamentally broken. In my opinion, the possibility of configuration hell with RapidSVN outweighs both its licensing and its support for "file://" URLs (which SmartSVN doesn't allow).

HPC and Programmability

Sat, 10 Jul 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Via Andrew Lumsdaine, a pointer to an interesting article in Communications of the ACM by Eugene Loh titled "The Ideal HPC Programming Language". A few key quotes:

These programmability studies began with a focus on programming languages, but the focus quickly shifted to other topics. Existing languages—notably Fortran...—proved remarkably adequate. Programming challenges stem mostly from other factors.

The DARPA HPCS program...sponsored the development of new programming languages: Chapel from Cray, Fortress from Sun, and X10 from IBM. Proponents of those languages would show early on how rewriting familiar HPC benchmarks in the new languages could reduce source-code volume substantially—tenfold reductions were not surprising—but rewriting these benchmarks even in Fortran achieved similar source-code reductions and corresponding improvements in expressivity.

People You Don't Want On Your Team

Fri, 18 Jun 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Study after study has shown that the biggest causes of software project failure are over-optimistic scheduling and unstable requirements. I think the only reason team dynamics isn't in the #1 spot is that it's hard for an outsider to judge after the fact. In my experience, though, how well people work together is a lot more important than how smart they are individually: everyone in the engineering group of the first start-up I joined was very good at their job, but when you put us together, our IQs somehow canceled out.

A Voice from the Back of the Room

Wed, 16 Jun 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Mark Guzdial recently posted another thought-provoking piece, this one about how teachers are biased toward assessing a class's progress by their interactions with its brightest students, and how important it is to assess understanding systematically to find out what's actually going on. We're still wrestling with this in Software Carpentry: what can we put on the web to help students determine whether they have understood a particular topic and are ready to move on?

The Cowichan Problems

Sat, 12 Jun 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Back in the 1990s, as the first wave of euphoria about parallel computing was topping out, I had a crazy idea: why don't we actually try to measure, or at least compare, the usability of different parallel programming systems? I left the field before taking the idea very far, but with talk about clouds and GPUs growing louder by the day, I think the idea is worth revisiting. My proposal is below the cut; I'd be interested in feedback.

Who Reports On The Other 97 Per Cent?

Tue, 01 Jun 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The BBC has posted a nice graphic of the latest Top 500 list of supercomputers around the world. It's pretty impressive, particularly if you're a Linux fan (check out the display by operating system). However, nobody would think that a list of the world's 500 richest people told them much about the state of the economy; I'd be much more interested in statistics on how much computing power is employed by the 97% or so of scientists who don't use a supercomputer.

Badges and Stars

Thu, 27 May 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The Open Notebook Science folks have developed a set of badges to help people label their work, ranging from "All Content — Immediate Release" to "Selected Content — Delayed Release". Like the badges for various Creative Commons licenses, or Tim Berners-Lee's proposed five-star system for rating open data, the biggest benefit of this kind of categorization is that it encourages people to think more clearly about what they are (or aren't) doing, and why.

We'll Know We've Succeeded If...

Tue, 18 May 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We will know the students taking this course have learned something if:

They understand why Titus Brown's Data Management Plan post is both funny and sad.

They have the knowledge, skills, and tools they need to do something about it.

Why Most Scientists Don't Like Computers

Fri, 14 May 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Psychology is fascinating: so much of what we think we know about people turns out not to be true, while so many everyday oddities turn out to have rational explanations (for some version of "rational"). For example, I've known for twenty-five years that most scientists dread the point in their work when they have to do something new with a computer. I've finally figured out why: it's because the yield-to-effort function is wildly discontinuous, and human beings hate that.

Why We're Self-Hosting

Mon, 10 May 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A couple of people have asked why we're planning to host and serve the content we're developing instead of using a combination of YouTube and Google Code, or one of the emerging online education services such as LearnHub or Supercool School. Part of the answer is longevity: while standards like SCORM are supposed to make e-learning content portable between different systems, in reality there is still a large degree of vendor lock-in, particularly with hosted services, and we don't want to find that our content has gone off-line because someone hasn't survived a market downturn. Hostable learning management systems like Moodle require more work to set up and administer, but are also more robust (at least for now).

Teaching Open Source

Mon, 12 Apr 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Over at opensource.com, Red Hat's Greg DeKoenigsberg has a post about a new collaboratively-authored textbook on open source software aimed squarely at undergrad courses. As Máirín Duffy points out in the first comment, it's very code-centric, but in my experience, that's the right approach: students won't be ready for discussion of design until they're proficient in coding [1]. I'm looking forward to borrowing lots from the book for Software Carpentry...

Measuring Science

Sun, 11 Apr 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Julia Lane, the director of the Science of Science & Innovation Policy program at the National Science Foundation, wrote an article for Nature a couple of weeks ago titled "Let's make science metrics more scientific". As the summary at the start says:

Existing metrics have known flaws

A reliable, open, joined-up data infrastructure is needed

Data should be collected on the full range of scientists' work

Social scientists and economists should be involved

The same points could be made about evaluating software developers (or any other kind of knowledge worker). The devil, as always, is in the details, and unfortunately I have to start doing evaluations before those details are worked out. Several of the supporters for this course need me to demonstrate its impact on the productivity of the scientists who take it (so that they can in turn justify their contribution to their funders). It isn't enough to ask students who have completed the course whether they think they know more about programming than they used to: ignoring the obvious problems of survivor bias and self-assessment, I would still have to demonstrate that making people better programmers also makes them better scientists. I believe it does, but belief is not evidence, and doesn't convey scale.

Simon Singh Wins (and So Does Science)

Thu, 01 Apr 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Simon Singh, the science journalist who was sued for libel by the British Chiropractic Association, has won the right to rely on the defense of "fair comment". (Full ruling linked from this Index on Censorship post.) Singh had pointed out that there's no evidence to back up BCA claims that their particular brand of pseudoscience could help with asthma and other ailments; it has taken him two years and £200,000 later to get this far, and it may be another two years before the matter is finally settled, but this is an important victory for everyone who believes in rational inquiry.

How Much Of This Should Scientists Understand?

Thu, 11 Mar 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Let's start with the problem description:

All of the Software Carpentry course material (including lecture notes, code samples, data files, and images) is stored in a Subversion repository. That's currently hosted at the University of Toronto, but I'd like to move it to the software-carpentry.org domain (along with this blog). However, software-carpentry.org is hosted with site5.com, who only provide one shell account per domain for cheap accounts like the one I bought.

It Seems That Everyone Cares

Sun, 24 Jan 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Ars Technica isn't primarily a science site, but even they are now worried about reproducibility in computational science. I think it no longer matters how important this "crisis" actually is—sooner or later, major funding agencies are going to mandate adoption of something like the Open Provenance Model. Problem is, given the current skill set of the average scientist, that will almost certainly translate into burden without benefit.

Big Science == Big Skills Gap

Wed, 20 Jan 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Over on Nature News, Eric Hand's article "'Big science' spurs collaborative trend" is subtitled, "Complicated projects mean that science is becoming more globalized." It talks about the benefits of international collaboration, but what it doesn't say is that sharing ideas, results, procedures, and software requires skills that aren't part of the standard curriculum. One of the main goals of the rewrite of Software Carpentry is to teach scientists some of what they need to know in order to do what Hand describes without heroic effort. I'd be grateful for suggestions about topics and tools that ought to be on the list, but aren't.

Was Designed To, But Didn't

Mon, 18 Jan 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Michael Clarke has written a thoughtful post exploring why the web hasn't disrupted scientific publishing, even though it was designed to do exactly that.

Whatcha Gonna Do When They Come For You?

Wed, 13 Jan 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

First it was pharma companies withholding "unhelpful" data, then it was ClimateGate, and now there's this:

One of the founders of the controversial 'Baby Einstein' range of products is taking the University of Washington to court in an attempt to force the institution's scientists to release their raw data to him...William Clark...wants records relating to two studies published in 2004 and 2007. The latter found an "association between early viewing of baby DVDs/videos and poor language development" while the former suggested "efforts to limit television viewing in early childhood may be warranted".

How We Got Here, and Where We Are

Sun, 10 Jan 2010 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I gave a talk in Santa Fe early in 1997 describing a set of articles I'd organized for the Summer 1996 and Fall 1996 issues of IEEE Computational Science and Engineering (now Computing in Science & Engineering on the subject, "What should computer scientists teach physical scientists and engineers?" After the talk, John Reynders (then the director of the Advanced Computing Lab at Los Alamos National Laboratory) challenged me to put my money where my mouth was and actually teach basic software development skills to working scientists.

Osmosis is Just a Fancy Name for Failure

Wed, 30 Dec 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

My last post linked to a PLoS paper by Dudley and Butte on developing effective bioinformatics programming skills. I asked, "How many hours do the authors think are needed to acquire these skills?" In response, Atul Butte said, "I think the ideal scenario is when one's research projects enable one to learn these skills, so that these skills get learned in a practical way outside the classroom too, while doing science," while Luis Pedro Coelho asked, "Does it matter over the long (or even medium) term? Isn't improving your skills even you if aren't being immediately productive what school is for?"

Dudley and Butte on Software Skills

Sun, 27 Dec 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Via Titus Brown, a new PLoS paper titled "A Quick Guide for Developing Effective Bioinformatics Programming Skills" by Joel Dudley and Atul Butte. Their recommendations are:

Programming languages

Embracing open source

Unix command-line skills

Keeping projects documented and manageable

Preserving source code with version control

Embracing parallel computing paradigms

Structuring data for speed and scalability

Understanding the capabilities of hardware

Embracing standards and interoperability

Put a high value on your time

I think all these things matter, but:

Double Standards

Fri, 18 Dec 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Nicola Scafetta is refusing to release the software on which he bases his claims that the sun is responsible for much of terrestrial warming during the last century. I obviously think that scientists should be required to do this as a condition of publication; coming as this does on the heels of Climategate, it will be interesting to see if journals finally start pushing in that direction. It also highlights the need to add more material to this course to cover packaging for release and data provenance.

Caesar's Wife

Thu, 26 Nov 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Improving the way scientists use computers isn't just about making them more productive: it's also essential to defending the integrity of their work. Stories like this one about a researcher struggling in vain for three years to replicate someone else's results can only undermine public confidence at a time when we need to make a lot of hard decisions in a hurry. Sadly, we have no one to blame but ourselves...

A Strange Obsession

Tue, 29 Sep 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I just spent a few minutes browsing these slides from a talk given in Karlsruhe in September by Microsoft's Fabrizio Gagliardi. The talk's title was "Cloud Computing for Scientific Research", and it's chock-full of big: mega-this, peta-that, and isn't it all exciting? The only mention of anything at the desktop scale is on slide 19, which mentions a plugin to allow MATLAB to talk to the cloud, and Excel views of Azure data. Once again, I'm puzzled (and a bit disappointed) that the world's premier desktop software company has decided to ignore what most scientists care about most. I'm equally disappointed that there was nothing at all in these slides about improving scientists' skills, especially since Microsoft has invested so heavily in improving its own processes. Oh well...

Another Reason to Care About Provenance

Mon, 21 Sep 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A vice president at ETH is resigning today because of accusations of fraud. A key lab notebook is missing, retractions have been retracted, and according to ETH President Ralph Eichler, "there is now no legal way of finding out for sure who was responsible for the falsifications."

Question: if someone accused you of falsifying results, how well and how easily could you defend yourself? How long would it take you to pull together all the notes, data, and programs you used three years ago to produce the paper being challenged? And would you career survive? Even if you "won", you would probably lose weeks or months of research time.

Is The Future Waving At You?

Sun, 30 Aug 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Cameron Neylon has been playing with Google Wave, and he likes it. His presentation at Science Online in London in August explains why (you can also watch video, though sadly there's no soundtrack). He's even writing robots to automate some scientifically interesting tasks. Nature News liked Wave too, which (a) reminds me yet again of how prescient Jon Udell's "Internet Groupware for Scientific Collaboration" was ten years ago, and (b) makes me wonder (also again) how much this course should be re-thought.

Who Owns Your Data?

Mon, 24 Aug 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Nature's "Great Beyond" blog reports another attempt to force climate scientists to release their data. I'm of at least two minds on this: I believe openness is absolutely crucial to science (and society as a whole), but I understand scientists' concern about being scooped, and equally their concern about having their work misrepresented or quoted out of context. Mostly, I come down on the side of openness—how about you?

Elsevier's Future, Version 0.1

Tue, 21 Jul 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Elsevier (a big scientific publisher) have unveiled their guess of what the future of scientific publishing looks like. Tabs? Got 'em. Audio? Yup. RSS feeds for updates, corrections, and comments? The raw data, complete with provenance information so other researchers can try to reproduce the results? Still waiting...

Big Code vs. Science 2.0

Mon, 01 Jun 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The original goal of this course was to give scientists and engineers the skills they needed to build large pieces of software without heroic effort. It's increasingly clear, though, that another goal is equally important: to help them take part in what's sometimes called "Science 2.0": the sharing of information through the Internet. Cameron Neylon's slides on capturing process are, like Jon Udell's on computational thinking, a good summary of the skills required—skills which overlap with, but are distinct from, those needed by software developers.

Empirical Software Engineering and Scientific Computing

Tue, 28 Apr 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The slides for my talk at the National Research Council on empirical software engineering and how scientists actually use computers are now up on SlideShare. The colors in some of the embedded images were messed up during upload, but the result should still be readable.

Open Science and Autism's False Prophets

Mon, 02 Mar 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Paul Offit has a new book out called Autism's False Prophets, which looks at how the myth about vaccination causing autism arose and spread. As his condensed essay on the subject says, it's a far from simple story, but one that has echoes in areas such as climate change where science and public policy must dine at the same table. I still haven't decided whether open science will make a difference to this or not: putting data, calculations, and papers freely available online in real time will help scientists talk to one another, but I don't think it will help them communicate with the other 99.9% of our species. Thoughts?

Das Kapital, Computational Thinking, and Productivity

Mon, 23 Feb 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Somewhere in The Age of Uncertainty, Galbraith wrote that what made Das Kapital and the Bible great books was that they were so large, and so full of contradictions, that everyone could find support in them for anything they wanted. I have felt the same way about the phrase "computational thinking" ever since I attended a workshop at Microsoft Research in September 2007. In one of the breakout sessions, six of us tried to operationalize our understanding of the term by coming up with questions for a quiz that could be given to someone to determine if he or she was thinking computationally. It quickly became clear that we meant very different things when we used those two words. It was also clear (to me at least) that this ambiguity was socially very useful, since (to switch metaphors) it allowed people to attend the same church while disagreeing on the nature of salvation. It's not a polite fiction per se, but rather a—um, damn, I don't know the word—a thing that no one looks at closely because doing so would cause discomfort or friction.

Computer Supported Collaborative Science

Wed, 18 Feb 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I've used the term "CSCS" a few times now; time to start groping toward a definition. "Computer supported collaborative science" (CSCS) is a specialization of computer supported collaborative work, which is the study of "how collaborative activities and their coordination can be supported by means of computer systems". Insert the word "scientific", and you have CSCS. More specifically, CSCS includes science 2.0, open notebook science, reproducible research, workflow & provenance, and other things modern computing technology can do to help scientists find and share information.

Cameron Neylon Says Interesting Things

Wed, 04 Feb 2009 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

This time, he has blogged about best practices for making scientific data available. I think this kind of thing will have a much bigger impact on scientists' productivity than any amount of parallel supercomputing, and that computer scientists could have a lot of impact by helping "real" scientists figure out how to do it better.

A Healthy Dose of Scepticism

Wed, 24 Dec 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Titus Brown's latest post (which opens with, "The latest hot idea for making a protein-protein interaction database leaves me lukewarm") should be read by every computer scientist who's "just trying to help":

...while tools can be helpeful, the fundamental problem is much more, well, fundamental: science is hard. Connecting the dots is hard. Thinking clearly about the problem and separating the wheat from the chaff, so to speak, is hard. I worry that for the majority of biologists, new tools are going to be more distracting than helpful. We need to build simpler, easier-to-use tools, not more complicated tools; we need to keep our focus on the goal (solving biological problems) and not just on intermediate stages like improving databases and building better prediction tools.

Science in the 21st Century

Thu, 11 Sep 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I'm at the "Science in the 21st Century" conference at the Perimeter Institute today. There are 32 people in the room right now: 23 are male and 9 are female, but only one is non-Caucasian, which pretty much matches the numbers in the picture from the conference dinner last night. That's about the same M/F ratio I see in science grad courses at U of T, but definitely not the ethnic distribution—wonder why? It can't just be a "seniority effect" — this is a pretty young crowd. We see the same thing at DemoCamp: non-Caucasians are often a majority n sci/tech classes and companies in the Greater Toronto Area, but definitely a minority on Tuesday nights. Thoughts? Michael Nielsen says that SciBarCamp was 50/50...

They're Breeding Like Rabbits

Fri, 01 Aug 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Cameron Neylon complains about the proliferation of networking sites, aggregators, and what-not for scientists. I think he's right: none of them will succeed until there's massive consolidation. Maybe LinkedIn or someone like that could offer a cheap-but-not-free service customized to scientists' need on top of its existing infrastructure?

Badge of Reproducibility

Wed, 23 Jul 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Coming back to the badge meme from earlier this week, John Cook's new Reproducible Research blog pointed me at this page on the EPFL site advertising a paper called "What, Why and How of Reproducible Research in Signal Processing". Notice the "Reproducible Research" badge? The "add your evaluation" link takes you to a formlet that lets you choose between:

I have tested this code and it works

I have tested this code and it does not work (on my computer)

I have tested this code and was able to reproduce the results from the paper

I have tested this code and was unable to reproduce the results from the paper

It's a good start...

Why Don't We Do This?

Wed, 21 May 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Source Code for Biology and Medicine is a peer-reviewed journal from BioMed Central devoted to, well, source code for biology and medicine. It's been around for at least a couple of years; based on a quick scan of four of their most popular papers, they seem to cover everything from getting and installing software to its numerical properties, user interface, and typical applications. This is very cool—but why isn't there something like this for computer science? All I can think of are Software: Practice & Experience and The Journal of Systems and Software, both of which are one meta removed from SCBM.

But I Was Gone Less than 48 Hours!

Fri, 16 May 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I left Toronto for Austin mid-day Wednesday, and got back at midnight last night. Lots happened in the interim, so here's a linkandthoughtdump (which I bet actually is one word in German):

Gave a talk about Beautiful Code to the Austin Python Users' Group Wednesday at Enthought's swanky offices. (They're the kind folks who provide web hosting for the Software Carpentry course.) About 27 people in attendance, and good discussion afterward; was grateful to Travis Vaught and Sergey Fomel for rides from the airport and to the hotel respectively.

Gave another talk titled "HPC Considered Harmful" at the Texas Advanced Computing Center's Second Annual Scientific Software Days. I was a bit nervous about telling people at a supercomputing center that focusing on massive parallelism and peak performance is wrongheaded, but there were a lot of nodding heads.

I made lots of notes from two other talks that I want to follow up on at some point:

Robert van de Geijn's FLAME system lets you draw matrix operations, then automatically generates the corresponding high-performance code. It's a great example of a real high-level programming tool for scientists (and yet another special case of what a real extensible programming system would support).

Eric Jones (also from Enthought) talked about a tool they're building that watches changes to variables in Python programs, and automatically generates interactive plots of their values. It sounds simpler and less impressive than it actually is; I've asked him to put together a screencast, and I think you'll be wowed—I was. (Later: Steve Eddings from The Mathworks sent me a link about data linking in MATLAB, complete with a video tutorial.)

At roughly the same time, half a world away, Diomidis Spinellis presented a study comparing the code quality of Linux, Windows, OpenSolaris, and FreeBSD. Very cool work; wish I'd been at ICSE'08 to ask questions.

Meanwhile, Dmitri Vassiliev, who is continuing his work on SlashID this summer, has discovered that generated code is next-to-impossible to debug. Not to be a one-note symphony or anything, but I said in that same article about extensible programming systems that the real challenge is not extending notation, but creating extensible debugging tools so that those notations and high-level representations can be fixed when they break. Robert van de Geijn doesn't think FLAME needs a debugger; respectfully, I disagree.

Science in the Open has a plea to scientists to make their raw data available, motivated by yet another irreproducible result.

Kosta Zabashta has posted early thoughts about integrating IRC into DrProject. (Gray on black? Kosta...your design skills rival mine...) I need to tell him that DrProject's RPC module doesn't handle tickets because Jeff Balogh is going to replace the entire ticketing system with an extensible one this summer, using his Dojo Form Editor as a front end...

Elisabeth Hendrickson has thoughts on automating tests for legacy web applications. Students, take note.

Thanks to Nick Jamil and others, we have instructions for installing DrProject on Windows. Yay!

Everything old is new again, including Ada and the Bletchley Park Colossus.

And then there's this:

SPOC

Mon, 14 Apr 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Regarding the idea of reproducible research, I stumbled over I-SPOC while looking through Google Summer of Code stuff. From their pitch:

The overall goal of this project is to build computational and social infrastructure to support the use of a new form of scientific communication called a SPOC (Scientific Paper with Open Communication). A SPOC combines a standard academic paper with open source computational models written in any publicly accessible computer language. SPOCs will (i) link computational results with the models that produce them, allowing independent verification and validation (ii) create incentives for cleaner, more transparent code and for the sharing of code (iii) enable others to extend and improve existing computational models and to verify model robustness (iv) bring computational models to life allowing faculty, students, and other scholars to see dynamic phenomena emerge and (v) have an enormous effect on the teaching of science.

Three Studies (Maybe Four)

Thu, 10 Apr 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

We're in the thick of picking students and projects for Google Summer of Code, which has inspired some less-random-than-usual thoughts. Here are two studies I'd like to do (or see done):

What has happened to previous students? How many are still involved in open source? How many have gone on to {start a company, grad school, prison}? What do they think they learned from the program? How much of the software they wrote is still in use? Etc.

Every one of the 175 organizations blessed by Google this year is using the same web application for collecting and voting on projects. From what I can tell, they're all using it in different ways: +4 means something very different to the Python Software Foundation than it does to Eclipse or SWIG. They're also using a bewildering variety of other channels for communication: wikis, IRC, Skype chat sessions, mailing lists (the most popular), and so on. Why? Is this another reflection of Jorge Aranda's finding that every small development group evolves a different process, but all those processes "work" in some sense, or is it—actually, I don't have any competing hypotheses right now, but I'm sure there are some.

And while we're on the subject of studies, I just read Hochstein et al's paper "Experiments to Understand HPC Time to Development" (CT Watch Quarterly, 2(4A), November 2006). They watched a bunch of grad students at different universities develop some simple parallel applications using a variety of tools, and measured productivity as (relative speedup)/(relative effort), where relative speedup is (reference execution time)/(parallel execution time), and relative effort is (parallel effort)/(reference effort). The speedup measure is unproblematic, but as far as I can tell, they don't explain where their "reference effort" measure comes from. I suspect it's the effort required to build a serial solution to the problem, and that "parallel effort" is then the additional time required to parallelize; I've mailed the authors to ask, but haven't heard back yet.

Meet the New Flaw

Mon, 31 Mar 2008 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

I was pretty excited when I heard that Microsoft was getting into scientific computing. As the world's biggest desktop software company, I figured they might understand that scientific computing and high-performance computing are not automatically the same thing, and that reliability and reproducibility are more important than peak performance. Turns out I was wrong: the workshop I attended last September was dominated by discussion of topics like GPU programming and computational grids that are still bleeding-edge computer science, rather than the nuts and bolts that would actually help most scientists be productive day-to-day, Microsoft's new HPC++ Computational Finance lab's site [since closed] has a lot on speed but nothing on correctness, et cetera.

Doomed to Repeat It

Tue, 02 Oct 2007 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Those who cannot learn from history are doomed to repeat it. (Santayana)

I spent a day and a half last week at a workshop on computational science education. There were lots of smart people in attendance, all very passionate about the need to teach scientists how best to use the awesome power of a fully functional mothership—sorry, of modern hardware and software—but as the discussion went on, I grew more and more pessimistic. I'm old enough to remember the first wave of excitement about computational science in the 1980s; dozens of university-level programs were set up (mostly by physicists), and everyone involved was confident that the revolution would be unstoppable.

Computational Scientists Still Don't Get It

Sat, 05 May 2007 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A workshop called "Software Issues in Computational Science and Engineering" is running in Uppsala, Sweden, this August. Here's their blurb:

Software for numerical computations faces multiple challenges. The software should be easy to use. Ideally, adaptation to new applications should be flexible, and extension to incorporate new numerical techniques straightforward. At the same time the software should execute extremely efficiently on various high-performance computing platforms. Accuracy and robustness are other key features. The overall challenge is to find ways to construct numerical software so that all these different goals are met simultaneously.

Sign Error: Five Papers Retracted

Mon, 19 Mar 2007 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Via Genome Biology (free registration for trial access required), news that scientists from the Scripps Institute have to retract five papers published in various prestigious journals because of a sign error in a computer program. As Gregory Petsko says in the article:

Their mistake has consequences beyond the damage to the unfortunate young investigator and his team. For five years, other labs have been interpreting their biophysical and biochemical data in terms of the wrong structures. A number of scientists have been unable to publish their results because they seemed to contradict the published X-ray structures. I personally know of at least one investigator whose grant application was turned down for funding because his biochemical data did not agree with the structures. One could argue that an entire sub-field has been held back for years...

Computational Result Retracted

Tue, 31 Oct 2006 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

From the latest Nature (Vol 443, No 7114, p 1013):

When a new, independent code is used for the calculations on which the conclusions of this Letter were based, the results reported for the evolution of obliquity cannot be reproduced. This code was written in the inertial frame and is more reliable than the one used in the Letter. In most runs, the obliquities can change by only a few degrees and attain large values in only a very few cases. In addition, the obliquity variation shown in the Supplementary Information, although correct, originates from changes to orbital inclination of the planet, and close encounters are not effective in causing large obliquities.

SciPy'06: First Morning

Thu, 17 Aug 2006 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Guido van Rossum's Keynote

Python 2.5 coming Real Soon (Sept 12)

Python 3000 is a brand-new revision of the language

Name chosen as a dig at Windows 2000, and so that it couldn't possibly be late

Fix design bugs dating from 1990-91 + get rid of deprecated features

First time Guido has allowed himself to be backward incompatible

Need process, but don't want to become C++ or the next Perl 6

Alpha early 2007, final a year later (early 2008)

Cares a lot about bringing users with him

Will go as far as 2.9 (run out of digits)

Changes:

New keywords allowed

dict.keys(), range(), zip() won't return lists

All strings Unicode; mutable 'bytes' data type

Binary file I/O redesign

Drop as an alias for !=

Etc.

See PEP 3099 for things that won't happen (e.g., programmable syntax)

Can't do perfect mechanical translation (dynamic languages)

Use pychecker-like tool to handle 80% of cases

Create instrumented Python 2.x that warns about "doomed" constructs

See PEP 3100 for the laundry list

Small points

Kill classic classes

Exceptions must derive from BaseException

int/int will return a float

Remove last differences between int and long

Absolute import by default

Kill sys.exc_type and friends

Kill dict.has_key, file.xreadlines()

Kill apply(), input(), buffer(), coerce()

Kill ancient library modules; more stdlib cleanup

exec becomes a funciton again

Kill `x` in favor of repr(x)

Change except clause syntax to exception E1, E2, E3 as err

Means "as" becomes a keyword

[f(x) for x in S] becoms sugar for list(f(x) for x in S)

General trend in Python away from lists toward more abstract structures

Kill raise E, arg in favor of raise E(arg)

zip becomes izip

lambda lives!

String types reform (bytes and str instead of str and unicode)

All data s either ibnary or text (conversions happen at I/O time)

Different APIs for binary and text streams

New standard I/O stack

C stdio has too many problems

Borrow from Java streams API (bleah)

Print becomes a function (boo)

See mailing list thread for justification

But I think that putting the output file at the end in print(x, y, file=z) is going to trip people up

Dict views instead of lists

dict.keys() and dict.items() return a set view

dict.views() will return a bag (multiset) view

Can delete from (but not add to) a view

Modifies the dict accordingly

Drop default implementations of comparison operators

<, <=, etc., currently compare by address — will raise TypeError

== and != should remain (useful)

Generic and overloaded functions (see his blog — running out of time)

Python sprints coming up (Aug 21-24)

Q&A

Py3K team is smaller than Perl6 — GvR optimistic that people will get the work done

Taking advantage of multicore?

GvR not a big fan of threads

Prefers loose coupling (one process per core)

Last attempt to get rid of the GIL slowed Python down by 2X

But neither Jython nor IronPython have a GIL

Will C-Python API change much?

Yup — just like the language

PyPy/type inference?

Python 4.0 or a sibling language

Travis Oliphant on the State of NumPy

The Parallel Tools Platform

Thu, 20 Jul 2006 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

The Parallel Tools Platform is an open source extension to Eclipse for writing, running, and debugging large parallel programs. This tutorial gives an overview of what it can do (with lots of pretty pictures); this article from CiSE goes into more detail. The lack of decent development tools (particularly debuggers) was one of the reasons I left parallel computing a decade ago; PTP almost looks nice enough to tempt me back into the pool...

Zipf's Law of Feedback

Mon, 17 Apr 2006 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Zipf's Law says that frequency is inversely proportional to rank, i.e., the second most common word in a large body of text will occur half as many times as the most common. I have observed an even steeper curve for Software Carpentry feedback: of the 336 corrections I've received, 212 are from one person (Adam Goucher), 21 from Matthew Moelter, 12 from the next two people, and then we're down into the curve's long tail. Has anyone ever done similar stats on the volume or frequency of contributions to software projects?

2020 Hype

Sun, 26 Mar 2006 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

A report from Microsoft Research called 2020 Science got a lot of press this week: Nature seems to think it's the biggest story of the year so far, and The Economist gave it three full columns. Sadly, amidst the gush about how computers are revolutionizing science, no one mentions that most scientists have no idea how reliable their programs are—in fact, most scientists don't even know how they would figure that out [1,2]. If someone submitting a paper to Nature said, "We didn't calibrate the equipment, we didn't write down the settings, and we have no idea what the error bars on our graphs should be," their work would be bounced without a second thought. Unless computational scientists decide to live up to those standards, the "revolution" that 2020 Science describes will be a long time coming.

AAAS Annual Meeting 2006

Mon, 20 Feb 2006 00:00:00 +0000

This post originally appeared on the Software Carpentry website.

Wednesday, 11:10 p.m.: phone call from Air Can'tada saying that my Thursday morning flight to St Louis has been cancelled because of bad weather. Next available is 4:00 p.m. Friday afternoon—two and a half hours after my workshop is due to end. No, they can't help me find an alternative carrier. Expedia can, though, and by midnight, I have a ticket on Delta, via Cincinnati.