How to extract DNA with household materials

2011 was the Year of Science in British Columbia, Canada. On April 10, a science fair was held at the Civic Center in the City of Prince George. The stall that attracted me the most, amongst many, was one instructing visitors to extract DNA from several available fruits: strawberries, bananas, kiwi, and nectarines. (The reason I was most attracted to this stall probably stems from a childhood desire to study medicine or some stream related particularly to Genetics…)

I was eager to see the DNA strands pop out of fruits and I decided to conduct the simple experiment. I took half a Californian strawberry, carefully smashed it in a Ziploc®, mixed it with saline water and some specific kind of alcohol, to eventually collect the chromosome strands from the solution and store it in a take-away test tube, which I still conserve. In this post, I present the simple steps you could follow to extract DNA using merely household materials. These steps are taken verbatim from a leaflet prepared by Genome British Columbia.

DNA Extraction Experiment

Materials

• Kiwi (or strawberry or banana)
• Table salt
• Bottled water
• Clear cup
• Spoon or straw
• Tape or elastic band
• Liquid dish detergent
• Cheesecloth (3 layers)
• Cold isopropanol (can be purchased at a drugstore, should be placed in the fridge to cool)
• Wooden or glass stir stick (I used wooden stick to stir the mixture, as explained below)

Preparation

• Make the buffer solution by mixing 1 tsp of table salt in 100 mL water. (Note: the salt solution will help precipitate proteins and carbohydrates away from the DNA.)
• Make the soap solution by mixing 3 mL (3/4 tsp) liquid soap with 27 mL (2 tbs) water.

Steps to follow

1. Scoop out the fruit flesh into a sandwich wrap and mash well for 2 minutes. (Note: mashing helps break apart the cells and loosen the tough cell wall. If using kiwi, peel the skin, since the skin comprises relatively dead cells, which can’t produce much DNA.)
2. Add 10 mL of buffer solution and grind for at least 5 minutes. Use your strength to really mash it up!
3. Assemble the filter by covering the top of a cup with the three layers of cheese cloth. Tape the cheese cloth around the cup.
4. Pour the fruit mash through the filter. Let the solution drip into the cup.
   • You can get extra juice by squeezing the mixture in the cheese cloth through the cloth.
5. Add 3 mL of the soap solution to the filtered liquid. Swirl gently to mix. (Note: the soap will break open the cellular and nuclear membrane so as to release the DNA.)
6. Pour 2 volumes of the cold isopropanol down the length of a straw (or the back of a spoon) into the fruit liquid.
   • The isopropanol needs to form a layer on top of the kiwi liquid. (Note: 2 volumes means twice the amount of the fruit liquid.)
7. Let the liquid sit for a while. The DNA should precipitate where the fruit liquid meets the alcohol. You can use the wooden stir stick to spool some out of the cup! There you go!

And that’s what I did as well. In the following photo you can see my small test tube containing my California strawberry DNA in some alcohol solution:

Strawberry DNA

Needless to say, don’t hesitate to try the DNA experiment at home — it’s really fun and instructive!

One final note: Interestingly enough, people using bananas rather than kiwi or strawberries, collected a far larger amount of DNA. I asked a geneticist friend of mine for the reason, and he said that the bananas were probably not organic. Non-organic fruits tend to have larger-sized chromosomes, hence producing more DNA upon extraction…

Our hits at ICSE ’12

In the past two semesters, I’ve been collaborating closely with other researchers to both learn from them and from what they’ve pointed at, as well as to contribute modestly to the body of knowledge, as is customary. Among our compositions, three hits were intended for three different workshops in this year’s ICSE in Zurich, Switzerland, and the three of them were accepted.

The first hit, “ProxiScientia: Toward Real-Time Visualization of Task and Developer Dependencies in Collaborating Software Development Teams,” which I coauthored with Kelly Blincoe, Adrian, Peppo Valetto, and Dana, is thus far the one whose lyrics I know the best, as you may have noticed here. We’ll be presenting this at CHASE, an arguably reputable workshop. Here’s a PDF of the paper. A funny constraint at CHASE, as in most other venues: limit the provision of your knowledge to 7 pages. One needs to inform ICSE about the existence of the concept of entropy in relation to data compression and the inherent computational difficulties to compress stuff. Note: Here in Canada we have a vast unused space and we don’t care of compressing; thus we do feel you, Switzerland :)…

The last two hits are mainly pedagogical reports on teaching software engineering in the face of modern constraints. The first such paper, and the second hit, is a concise synopsis I wrote with Dana, my supervisor, having TA-ed for her before as well. It’s titled “Teamwork, Coordination and Customer Relationship Management Skills: As Important as Technical Skills in Preparing Our SE Graduates” and will appear at EduRex. A preprint (PDF) can be found here. In my view, the learning outcomes we summarized as well as the challenges faced throughout the instructional process are the major contribution. To provide some context, we included a section alluding to the types of projects we had students develop, as an anonymous reviewer pointed at.

The third and final hit is a paper I coauthored with Dana, Casper Lassenius, Maria Paasivaara, and Adrian, titled “Teaching a Globally Distributed Project Course Using Scrum Practices” (PDF here). The intent here was to report on observations regarding the applicability of agile methods (e.g. SCRUM) in GSD settings. The ecology used for observation was the GSD environment set up for the GSD course taught at the University of Victoria, Canada in collaboration with Aalto University, Finland. (I’ve dedicated a post to that course since it was my second PhD course and an interesting experience at the same time.) This is an important report on the challenges students faced in employing scrum practices in GSD teams. In particular, student teams (three, in total) comprised Canadian and Finnish teammates separated culturally, temporally, and geographically, noting that the linguistic distance wasn’t really a factor. It will be great to argue on the challenges faced (and lessons learnt, now that the course is over) with other workshop participants who had to resort to similar instructional strategies/designs and who experienced all sorts of challenges for all sorts of reasons.

More updates to come in future posts as we prepare for ICSE ’12.

Methodological considerations

McGrath’s classical treatment of the social research process elicits several intrinsic facts about conducting empirical research, such as the individual strengths and drawbacks of each available/new method, or the collective strength of at least two methods employed conjunctively to tackle some research question.

It is important, however, to distinguish that empirical methods in software engineering and the social sciences that deal with human systems, for that matter, are susceptible to converging towards dismality unless at least one formal method (theoretical strategy) is also employed. McGrath alludes to a similar perspective on p. 159, wherein he argues that the methods of Quadrant IV are crucial for philosophical reasons (“research is scientific”) and empirical ones (“theories are built from such observations”). It is a relief to read such an affirmation because, in turn, it does affirm the fact that science is only meritocratic in its entirety. This view becomes a little too misty when jumping to social science research, wherein conclusions along different studies using different methods for the same problem may not consistently converge.

If the overall objective of social research is to elicit truths about human systems, then Russell’s “recommandation for future generations” resonates in my mind: “If something is true, you should believe, otherwise you shouldn’t. If you can’t find out its truth, you should suspend judgment.” Can social researchers afford to suspend judgment when the methods they have employed have yielded inconsistent results or conclusions for whatever problem they’ve tackled?

(One note of correction, given that we’re philosophizing on science: When describing what computer simulations are on p. 159, McGrath mentions that the designed model is “complete and logically closed.” Such a model, alas, cannot exist because co-existence of completeness and consistency is precluded by Gödel’s Incompleteness Theorems…)