Tag Archives: Functional Requirements

Are bad or sub-optimal designs in nature supportive of atheism?

Engineer Bill Pratt explains why “bad design” is not supportive of atheism at Tough Questions Answered.

Excerpt:

The other day I heard an atheist say that the fact that he sees poor design in the natural world leads him to the conclusion that the Christian God does not exist. Here is the argument:

  1. An omnipotent, omniscient, omnibenevolent creator God would create organisms that have optimal design.
  2. Organisms have features that are sub-optimal.
  3. Therefore, God either did not create these organisms or is not omnipotent, omniscient, and omnibenevolent.

There are several things wrong with this argument, but I want to focus on premise 2 – organisms have features that are sub-optimal.

I am an electrical engineer who has been designing integrated circuits (IC) for 20 years, either personally or through managing other engineers. I am extremely familiar with IC design. Over the years, I have often heard young engineers, who did not design a particular IC, criticize the design of that IC by saying it is sub-optimal, that they could do a better job. I have then seen these same engineers eat crow when they finally talk to the original designer and discover the constraints that original engineer was under when he designed the IC and the purposes for which he designed the IC.

It is impossible to judge a design as optimal or sub-optimal without knowing the purposes of the designer and without knowing the constraints the designer faced during the design. Young engineers just assume that they know both when they look at somebody else’s design. After being embarrassed a few times, they usually drop this approach and gain some humility.

Engineers know that designs are always a balance between competing NFRs – non-functional requirements. Many of the the NFRs are often opposed to each other, like speed and memory. If you want something fast, it often requires more memory. If you want something cheap, you sacrifice memory and your program runs slower because there is more disk access.

Even more than that, atheists assume that if God designed organisms, then he should have designed it for our benefit – to make us happy, healthy and long-lived. But that is not God’s purpose for making us. He doesn’t want us to be happy (apart from him), he wants us to know him. And there is nothing to say that designs that are “bad” for happiness are also bad for knowing God.

How do we know that some parts of DNA really are non-functional?

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!