Science

I recently ran across a discussion of quantum mechanics from C. S. Lewis.

The older scientists believed that the smallest particles of matter moved according to strict laws: in other words, that the movements of each particle were “interlocked” with the total system of Nature. Some modern scientists seem to think — if I understand them — that this is not so. They seem to think that the individual unit of matter … moves in an indeterminate or random fashion; moves, in fact, “on its own” or “of its own accord.”

He goes on to explain that the macroscopic behavior of matter appears deterministic because the average behavior of billions of particles is very regular. His explanation is remarkably cogent for a medieval literature professor writing in the 1940’s. He then discusses the philosophical consequences of quantum mechanics.

Now it will be noticed that if this theory is true we have really admitted something other than Nature. If the movements of the individual units is “on their own,” … then those movements are not part of Nature. It would be, indeed, too great a shock to our habits to describe them as super-natural. I think we should call them sub-natural. But all our confidence that Nature has no doors, and no reality outside herself for doors to open on, would have disappeared. There is something outside her, the Subnatural. … And clearly if she thus has a back door opening on the Subnatural, it is quite on the cards that she may also have a front door opening on the Supernatural …

From Miracles by C. S. Lewis, chapter 3.

Related post:

The world looks more mathematical than it is

Open University videos on gradient, divergence, and curl

Grad:

Div:

Curl:

Related link:

Div, Grad, Curl and All That

According to this article from National Geographic News, some experts now believe the number of dinosaur species has been overestimated. Some specimens that were previously believed to be distinct species are now believed to be juvenile specimens of other species. (Hat tip to Eric Geiger.)

Keith Baggerly and Kevin Coombes just wrote a paper about the analysis errors they commonly see in bioinformatics articles. From the abstract:

One theme that emerges is that the most common errors are simple (e.g. row or column offsets); conversely, it is our experience that the most simple errors are common.

The full title of the article by Keith Baggerly and Kevin Coombes is “Deriving chemosensitivity from cell lines: forensic bioinformatics and reproducible research in high-throughput biology.” The article will appear in the next issue of Annals of Applied Statistics and is available here. The key phrase in the title is forensic bioinformatics: reverse engineering statistical analysis of bioinformatics data. The authors give five case studies of data analyses that cannot be reproduced and infer what analysis actually was carried out.

One of the more egregious errors came from the creative application of probability. One paper uses innovative probability results such as

P(ABCD) = P(A) + P(B) + P(C) + P(D) – P(A) P(B) P(C) P(D)

and

P(AB) = max( P(A), P(B) ).

Baggerly and Coombes were remarkably understated in their criticism: “None of these rules are standard.” In less diplomatic language, the rules are wrong.

To be fair, Baggerly and Coombes point out

These rules are not explicitly stated in the methods; we inferred them either from formulae embedded in Excel files … or from exploratory data analysis …

So, the authors didn’t state false theorems; they just used them. And nobody would have noticed if Baggerly and Coombes had not tried to reproduce their results.

Related posts:

Irreproducible analysis
Highlights from Reproducible Ideas
Reproducible Ideas blog winding down

There are more termites in the world than there are elephants. Not only that, the total mass of the world’s elephants is roughly 1/1000 the total mass of the world’s termites. The big, visible animals, the ones that first come to mind, are a small fraction of the total.

Something similar is true of software projects: the big, visible projects, the ones people write about, are a small fraction of the total. Certainly there are more small projects in the world than large projects. And I imagine more programmers in total work on small projects than on large projects. I don’t have any hard numbers on this, and I doubt anyone else does. Most hard numbers come from large, visible projects! Who is going to do a census of all the little one-man projects that go unnoticed?

This post is a continuation of a comment I made as part of the discussion following my blog post on medieval software project management. My contention there was that most projects involve one developer, have no written requirements, and no external testing. That may not be correct, but I imagine it’s closer to the truth than assuming everyone works on projects with a dozen developers, formal requirements documents, and a staff of testers.

The first books on the “right” way to develop software codified the experience gained from working on enormous federally funded software projects. For example, the recommended practice was to spend huge proportion of the total effort in up-front planning. While that made sense when coordinating the efforts of thousands of contractors in the days of punch cards, it doesn’t make as much sense now. The agile software development movement began when people realized that the world had changed and the “best practices” of a previous generation were not optimal for smaller projects and vastly superior hardware.

Agile software development has replaced the best practices of the 1960’s in many organizations. However, there is still a strong tendency to think that small projects should use the same tools and techniques as large, enterprise projects. Most books are written about medium to large projects and many developers worry unnecessarily about scaling up their projects. (”What if I get a million visitors an hour to my web site?” You should be so lucky. Worry about that after it becomes a remote possibility.) Few pundits give advice that scales down, that is, advice appropriate for small projects. I wrote about one exception in a previous post in which Rob Page suggests different methods for projects with a budget of less than $1M and projects with a larger budget.

Related posts:

Million dollar cutoff for software technique
Enterprising software
Medieval software project management

The Hawthorne effect is the idea that people perform better when they’re being studied. The name comes from studies conducted at Western Electric’s Hawthorne Works facility. Increased lighting improved productivity in the plant. Later, lowering the lighting also increased productivity. The Hawthorne effect says that the productivity increase wasn’t due to changes in lighting per se but either the variety of changing something about the plant or the attention that workers got by being measured, a sort of placebo effect.

The Alternative Blog has a post this morning entitled Hawthorne effect debunked. The original Hawthorne effect was apparently due to a flaw in the study design; correcting for that flaw eliminates the effect.

The term “debunked” in the post title may imply too much. The effect in the original studies may have been debunked, but that does not necessarily mean there is no Hawthorne effect. Perhaps there are good examples of the Hawthorne effect elsewhere. On the other hand, I expect closer examination of the data could debunk other reported instances of the Hawthorne effect as well.

The Hawthorne effect makes sense. It has been ingrained in pop culture. I heard a reference to it on a podcast just this morning before reading the blog post mentioned above. Everyone knows it’s true. And maybe it is. But at a minimum, there is at least one example suggesting the effect is not as wide-spread as previously thought.

It would be interesting to track the popularity of the Hawthorne effect in scholarly literature and in pop culture. If the effect becomes less credible in scholarly circles, will it also become less credible in pop culture? And if so, how quickly will pop culture respond?

The traditional approach to cancer treatment has been to try to eradicate tumors. Eliminating a tumor is better than shrinking a tumor, so this approach makes sense. But if you try to eradicate the tumor and fail, you may leave the patient worse off. If you kill 90% of a tumor with some treatment but leave 10%, the remaining 10% is resistant to that treatment. You may have made the tumor more deadly by removing the weaker portions that were suppressing its growth. This explains why cancer treatments sometimes appear to be quite successful, dramatically reducing the size of tumors, without improving survival.

Sometimes one treatment will shrink a tumor as much as possible as a prelude to another treatment, such as shrinking a tumor with chemotherapy prior to surgery. But if only one treatment is being used, the situation may be like the old saying that you don’t want to wound the king. If you’re going try to kill the king, you’d better succeed.

In a recent interview on the Nature podcast, Robert Gatenby of Moffitt Cancer Center advocates an alternative approach, treating cancer as a chronic disease. Instead of killing as much of a tumor as possible, it may be better to kill as little of tumor as necessary to keep it under control. Patients would continue to take anti-cancer treatments for the rest of their lives, just as patients with heart disease or diabetes take medication indefinitely.

Related post:
Repairing tumors

Isaac Newton famously said

If I have seen farther than others it is because I have stood on the shoulders of giants.

Later Mathematician R. W. Hamming added

Mathematicians stand on each other’s shoulders while computer scientists stand on each other’s toes.

Finally, computer scientist Hal Abelson quipped

If I have not seen farther, it is because giants were standing on my shoulders.

(Thanks to Mark Reid for the Hamming quote.)

The most recent Nature podcast (21 May 2009) has a news story about Down’s syndrome and cancer. Most types of cancer are much less common among people with Down’s syndrome. Since Down’s syndrome is caused by an extra copy of chromosome 21, researchers naturally want to know whether a gene on that chromosome is responsible for the reduced incidence of cancer. The podcast interviews researchers from two promising studies of candidate genes.

Here is the abstract of the medical paper discussed on the podcast.

Related post: Cartoon guide to cancer research

My frustration with personal productivity systems like GTD is that they’re all about projects and tasks. They leave out a third category: programs. GTD thinks of a project as something that can be broken into a manageable number of tasks and scratched off a list. But programs go on indefinitely and cannot be divided into a small number of one-time tasks.

I’m using the word “program” as in an “exercise program” or a “research program.” (I could think of my exercise program as a project, but it’s one I hope not to complete for a few more decades.) Sometimes there is a neat hierarchy where programs spawn off projects that can be divided into tasks. But sometimes you just have programs and tasks.

One of my frustrations with managing software development in an academic environment was the large number of programs disguised as projects. (Sorry, I know it’s confusing to talk about “programs” in the context of software development and not mean computer instructions.) You can’t manage programs as if they were projects. For example, you can’t talk about “after” project is done if it’s not really a project but a never-ending program. You have to either acknowledge that a program is really a program, or you have to have some way to make it into a finite project.

Here are some of my favorite posts from the Reproducible Ideas blog.

Three reasons to distrust microarray results
Provenance in art and science
Forensic bioinformatics (continued)
Preserving (the memory of) documents
Programming is understanding
Musical chairs and reproducibility drills
Taking your code out for a walk

The most popular and most controversial was the first in the list, reasons to distrust microarray results.

The emphasis shifts from science to software development as you go down the list, though science and software are intertwined throughout the posts.

I’m in the process of folding ReproducibleResearch.org into the new ReproducibleResearch.net site. I will be giving the .org domain name to the folks now running the .net site. (See the announcement for a little more information.)

As part of this process, I’m winding down the blog that I started last July as part of the ReproducibleResearch.org site. I plan to keep the links to my old posts valid, but I do not know whether the new site will have a new blog. I wrote about reproducible research on this blog before starting the ReproducibleResearch.org site, and I will go back to writing about reproducible research here. (See reproducibility in the tag cloud.)

I wanted to point out an article by Steve Eddins posted this morning: Reproducible research in signal processing. His article comments on the article by Patrick Vandewalle, Jelena Kovačević, and Martin Vetterli announced recently on ReproducibleResearch.org.

Readers interested in reproducible research may also want to take a look at the Science in the open blog.

Related posts:

Irreproducible analysis
Using Photoshop on experimental results
Highlights from Reproducible Ideas

The latest episode of the Science and the Sea podcast explains how a protein that gives a certain species of jellyfish a faint glow is useful in research into cancer and other diseases.

Related posts:

Cartoon guide to cancer research
Naked mole rats and cancer
How to treat a stingray wound

Everybody thinks Dilbert is about their job. But this cartoon really is about my job. It does a remarkably good job of summarizing what it’s like to work in cancer research.

Related posts on cancer research