Software analogy:

1. When you find a bug (essentially, an undesirable side-effect), it is probably NOT the only one. Every bug you find suggests more hidden bugs that simply have not been found yet.

2. When you correct a bug, each correction must be reviewed and tested very carefully, in case it introduces a new bug. The more lines of code in the correction, the greater the chances of introducing new bugs.

3. Even if the source code of the software was fully available (the equivalent of knowing the function of EVERY gene) and the software was 100% fully documented (the equivalent of knowing the interactions between genes and related groups of genes and their functions, knowing every detail of how the WHOLE system works, and knowing the overall system design and specifications), every minor change in the software must still be reviewed and tested many times, because each change can still introduce a bug (as has happened in many software projects). We don't have the source code and documentation nor the complete design and specifications of genomes. If you make changes in such a poorly understood system, you will almost surely introduce bugs -- unintended side-effects.

4. Some bugs are so obvious because their effect are manifested immediately (system crash, software does not work, a function fails, etc.). But other bugs are subtle. They might occur only under certain conditions, which may seldom happen. And perhaps they may cause a crash only under very rare conditions. Sometimes, it is very hard (or not known how to do so) to reproduce a bug, ie to recreate the conditions that cause it to occur. These happen in software systems which are totally under human control and whose complete source code and documentation are available to the designers and programmers. How much more in genomes?

5. There's an approach to software development called genetic algorithms (GA). In GA, you don't develop software line-by-line. You create a population of software with different random changes introduced, and using a fitness function, you test each software in the population for fitness. The least fit are eliminated. You then introduce more random changes (like a random mutation) or combine parts from different versions (like introducing sex), and eliminate the least fit, simulating the natural selection process of evolution. In fact, the software EVOLVES towards a version that gets fitter and fitter. Such software are generally much more robust than their human designed counterparts. But when you read the source code, it is opaque and very hard to understand, unlike software which have been painstakingly written in accordance with software quality standards. Here's the kicker: when the GA software has problems, the developers usually don't dig into the source code to change a line or to insert a new line. What they do is to RERUN the GA. In short, software developers will *do conventional breeding, not genetic engineering*.

More can be said, but the above should give you an idea. From the perspective of real engineers, "genetic engineers" are really, really stupid.

Happy new year to all,

Roberto Verzola