davidbau.com

Innovation, Copying, and Eukaryotes

Is it bad to copy-and-paste code?

When you are just beginning to learn to program, you discover that it is not easy to start from scratch. The easier way to program is to copy somebody else's program and then modify it.

But as you get further along, you quickly learn that the copy-and-paste technique is verboten in programming...

Copies And Cognitive Dissonance

Any programmer will tell you why copy-and-paste is a bad thing.

The standard party line: "Don't copy code. Reuse the old code." - "Reused code is smaller, cleaner, and more efficient." - "Copied code is unmaintainable." - "If there is a bug in copied code, you will have to track down all the copies to fix it." - "Abstract your concepts, encapsulate your implemenations, and reuse your libraries." Good heavens, don't copy your code.

Copied code is harder to understand than reused code. We humans think in terms of canonical platonic models. For example, once we know how to sort data, we would like to have a single concept for "sorted data," which deals with nulls and infinities and ties and edge cases in the same way everywhere. If there were a dozen different ways to sort things, it would drive us bananas.

So we train programmers to go back to the original code and modify it and generalize it when we need it to do something new. We add features, add parameters, wrap things up as reusable functions, classes, templates, or languages. We prefer to build towers of abstractions that allow us to reuse and improve a single authoritative copy of the code. In programming, standardization rules supreme: we abhor the idea of duplicating any parts of a program.

And this conventional wisdom works well for small, low-level pieces of code.

But once you start working with larger pieces of code, I'm not so sure that the argument against copying is actually so smart. The bias against copies comes from the way our brains work, but the demands of the real world are not always so clean and logical.

Reuse and Risk

Our tendency to favor code reuse over copy-and-paste has a real disadvantage that we rarely give credence to. Code reuse hampers innovation, because code reuse makes it more expensive and riskier to try anything new.

For example, suppose you are making a cool new database at Microsoft and you want something that is just-like a classical MS-DOS filesystem but slightly different. Maybe it deals with unlinking deleted files differently, and maybe that little change is the key trick for improving reliability of your easy-to-use database.

If you went and modified the actual filesystem that the operating system uses, there is a huge set of things that depend on that code, and you'd probably cause lots of programs that run on Windows to fall down, if not due to outright crashes, then certainly due to subtle bugs. While improving your database, you might break your web browser. You might never get the Norton antivirus program to ever work again. The whole "modify the one and only filesystem" approach would never get very far.

But why did you ever think the new filesystem was a cool idea in the first place? Because in the lab, you made a private copy of the filesystem code that you tweaked and only used for certain things. You broke certain assumptions, but in your own little copy, your database ran swimmingly well. Your private filesystem was better than the standard one - for the limited set of things that you wanted to do. It might work great in addition to the plain old filesystem.

What would happen if you showed your team that you had done this by copying a hundred thousand lines of filesystem code and making a few changes here and there? Every senior engineer would be screaming at you to merge your new idea into the old one. Copying a 100,000 lines of code is evil. It is inefficient, unmaintainable, and a huge cognitive dissonance. No matter that it might be impossible to actually incorporate your clever modification into the original system without killing it - the dislike of making a new copy runs far too deep for it to be considered practical. Better to generalize the old code than to copy it, even if it takes another hundred thousand lines of code to generalize.

And so you would never ship your product.

Copying is sometimes the best way to make a risky bet. But our bias against code copying means that it tends to be much harder to take risks.

And maybe that is a mistake.

Biological Innovation

Copy or Modify?

What made me think about this Innovator's Dilemma is that the same choice is faced by evolutionary systems in biology, and an interesting paper on the topic appeared in Nature today.

When it comes to copying, there are two different styles of genomes you find in biology:

1. On one side, we have some species that have genomes that are ruthlessly efficient, with only a single canonical copy of a gene for any given function. When you crack open this kind of genome, you are quickly struck by the elegance of the design - the DNA lays itself out almost like source code. In this sort of genome, every gene serves its essential and unique purpose, and you can even see at times that the genes seem to organize themselves into functional subdirectories of related code. Look at the lambda phage genome and you will realize that a master programmer wouldn't have done a better job than natural selection has somehow managed to do.
2. On the other side, we have some species that have flamboyantly messy genomes, with lots of disorganized, dead, and commented-out code, and many of extra copies of almost-the-same code doing the same thing over and over. Reading these genomes is like reading an extremely bad book, with the same point being made repeatedly, with lots of the same paragraphs and sentences copied five or ten times over. A programmer who checked in code like this would be fired on the spot; it comes as no surpise that the code was generated by a random process.

Why are some genomes so cleanly efficient and others are so sloppy? (Maybe intelligent design people will suggest that God must have been involved in the design of one type and not the other! - just joking...)

The answer has to do with recombination and meiosis. The tiny, boring single-celled prokaryotes and viruses are the creatures that have the efficient well-designed genomes. Bacteria avoid the enormous mess and cost of sexual reproduction; they duplicate their genomes with few errors, and they very rarely introduce a spurious copy of a gene. The result is a finely tuned, but simple program: the result of billions of years of continuous spot-bugfixing.

The beautiful, diverse, and innovative eukaryotes - all the trees and mammals and yeasts, with feathers and brains and chlorophyll and all sorts of amazing inventions - these are the creatures that have sloppy genomes. Somehow, the process of mixing up the genetic code of two parents results in a far greater degree of innovation than just spot-changing one line of code at a time. And it is apparent, when reading the DNA, that mixing up genes involves lots of unnecessary code duplication.

Copy-and-paste is messy and hard to understand. But - at least in biology - it seems that the occasional copy-and-paste is essential to large-scale innovation. You don't get flight, immune systems, hemoglobin, or human self-awareness with clean, minimal code. The most innovative designs come from the sloppiest code.

Measuring Prevalence of Copying

Biologists have long noticed that many of the genes in eukaryotic genomes are approximate copies of each other. They have long been aware that over the eons, copy-and-paste has sometimes resulted in evolutionary innovation.

But what has been mapped for the first time in work in today's Nature is the amount of copying that is going on in our genes. And the result is a surprise: copying is no side-show, no rare event. It is stunningly common.

Previous analysis of single nucleotide polymorphisms - the one-at-a-time base pair mutations that we all learned about in biology class, suggested that about 0.1% of our base pairs vary between individuals in our species - and that even when compared to other species like chimpanzees, we might only be different by 1%. How can such miracles of evolution as oak trees and human beings emerge from such a low level of changes in point mutations like this? "On enormous time scales," went the party line in biology, "small changes add up." It is like imagining bugfixing your way continuously from the ENIAC to OS X - maybe it would be possible over billions of years.

But today's report on copy-number variations has strikingly different numbers. There is so much copying going on in the human genome, and so much variation in how much copying appears within any individual, that about 12% of the human genome is subject to active copy-and-paste variations. In other words, I have different numbers of copies of many thousands of genes than you have in your DNA. More than one out of ten of the lines of our genetic code is actively in the process of being copied-and-pasted a different number of times, and natural selection is weeding through an enormous amount of variation in the presence of and absence of these copies - within us.

These dramatic numbers suggest that the spot-bugfixing model may not actually be the main way that evolution works at all. Copy-and-paste is not just an curious side-techinque in genetic evolution. Copy-and-paste appears to be the main way genetic variation in eukaryotes works. Copy and paste is emerging as very engine of genetic innovation.

In Defense of Copying

And so, as programmers, when somebody comes to you with a huge piece of copied-and-pasted code, I would make this suggestion.

Think about the difference between prokaryotes and eukaryotes, and hesitate for a moment before demanding that they merge their code into the original. Ask yourself whether messy, unmaintainable, hard-to-understand proliferation of copies might actually be the key to innovation.

Copying may be a very good thing.

Posted by David at November 23, 2006 06:39 AM