ECM sent me this post from Uncommon Descent about DNA and software design.

Perhaps I should begin by explaining explaining how software is made. The customer gives you a list of use case, which are descriptions of things that you expect the finished software to do. This list of expected system behaviors is called the “functional requirements”. There are also “non-functional requirements” that the user will not see, such as how easily the components of the system can be maintained or tested.

Now consider the post by William Dembski. He writes:

One of the main arguments to support evolution appeals to shared non-functional structures between organisms. Since design entails design for function, shared non-functional structures would suggest common ancestry in the absence of common design. But how can we tell whether something is truly non-functional?

Then he cites an e-mail sent to him by a software engineer, who explains how a lot of code is included to address exception handling and non-functional concerns.

As a programmer, sometimes I spend a lot of time designing error-detection and/or error-correction algorithms (especially for dealing with user input). Some of these functions may never, ever be used in a real-life situation. There are also various subroutines and functions that provide either exotic or minor capabilities that, likewise, maybe be used very seldom if at all. But they are there for a reason. Good programming practice requires considerable extra design and implementation of features that may only rarely, if ever, be used.

If someone were to cut out and eliminate these sections of code, repairing what’s left so that the program still functions, the program may work perfectly well for just about all situations. But there are some situations that, without the snipped code, would create havoc if the program tried to call on a function that was no longer there or that was replaced by some different function that tried to take its place. (Ask yourself what percent of the functionality of your spreadsheet or word processor program you use, and then ask if you would even notice if some of the lesser-known functionality were removed.)

I think biological life is like that. It seems to me that if some DNA code can be successfully removed with no apparent effects, one possibility is that the removed portion is rarely used, or the impact of it not being there has effects that are masked or otherwise hidden.

Perhaps redundancy is what was removed, meaning the organism will now not be quite as robust in all situations as before. I can give a kidney to someone else and suffer no ill effect whatsoever… until my remaining kidney fails and cannot be helped by the redundant one that I gave up (which situation may never, ever really occur due to my general good health).

P.S. Being able to snip something with no apparent ill effect may in fact provide support for ID by showing that the system was so well engineered that it could automatically adjust to a certain degree, and in most cases completely (apparently). It would be interesting to see some ID research into some of the evo cases that are being used to support the various flavors of junk DNA, to see what REALLY happens long term with the new variety now missing something snipped.

Sometimes, I forget that most of the world is trying to assess where biological systems are designed without knowing what engineers know about how the process of engineering.

Consider the example of implementing caching in order to reduce the frequency of network and database calls. Making a call to a remote system over a network can be very slow if there is lot of traffic congestion. The same thing applies to reading from a database or the file system. Engineers have invented a solution to this problem called “caching”. This basically means keeping the data you use the most often, or the most recently, in memory. It helps you to avoid looking up the same data over and over.

Notice that caching doesn’t do anything for the functional requirements. Instead, engineers are writing a whole bunch of code to address a non-functional requirement: performance. That caching code still has to be designed, written and tested, but the user will never see it produce any external behavior. In fact, the user will not be aware of the caching module at all!