Pattern recognition and reverse engineering (the heart of ID, since “ID is the search for patterns which signify intelligence”) …

Do you claim that the activity IDists call design detection would be called reverse engineering by engineers?

If so, is this notion getting any traction within the ID movement?

Software development is an activity of almost constant design.

God: “I going to need to refactor that last bit of doggie genome I just wrote, but for now it works.”

Every small change must prove itself immediately and carry its own weight, otherwise it will be selected away.

Significantly, 94% of the time it won’t even be statistically noticed .

Therefore, evolution cannot occur along lines that require forward reasoning.

Agreed, as evolution has no future goal.

Evolution is simply the reward a mutation gets for surviving another generation.

“1. Which of the tools ID provides are you using for such calculations?”

Irreducible Complexity. See, specifically, my paper which uses computability theory as a theoretical basis for IC.

“Could you provide an example of software you’ve treated that way?”

What we do is a slight modification of this. We have a custom content management system that we use for advanced modes of content management. There are parts of it that are useful to us, the developer, and parts that are useful to the users. If a part of the interface requires knowledge of loops to implement, we hide it from the user, and if it doesn’t, we generally show it. For instance, custom HTML is within the scope of things that advanced customers can do, but custom layouts that require iterating through design elements are usually not.

“How much unnecessary work is life/DNA imposing on us and how is it calculated?”

I think you’ve misunderstood a little what I’m saying. Life/DNA isn’t imposing unnecessary work. Evolution is what is doing the work in the “life” scenario, and it is incapable of performing what I am classifying as “unnecessary work” (i.e. forward reasoning). Therefore, evolution cannot occur along lines that require forward reasoning. Applications of this are available in my referenced paper.

Pattern recognition and reverse engineering (the heart of ID, since “ID is the search for patterns which signify intelligence”) will be a superior method to elucidating functional designs versus Darwinism.

I laid out the reasons here why Natural Selection is the wrong heuristic to evaluate the existence of functional architectures, and why it will fail to detect function when it would otherwise be evident to an engineer:

Airplane Magnetos, Contingency Designs, and Reasons ID will Prevail

Thus, it stands to reason, the Design paradigm is scientifically superior to natural selection in the identification of designs in nature!!!!

Therefore, ID, by providing a theory of design, and ways of measuring/determining the types of systems which require a designer (and to what degree), give software engineers both a way of determining whether their interfaces are unintuitive, and also give them a way of identifying sections of code which are especially prone for the introduction of bugs.

A very easy way is sequence comparisons to establish linguistic patterns, and thus reverse engineering the syntax and grammar of systems.

Violations of linguistic patterns suggest bugs. There may be grammars which can be elucidated via DNA comparisons across all species.

John Sanford showed me some of the work of ENCODE. My jaw dropped! There will be much fruitful research, maybe even $$$ here.

I was recently a participant in a several-days-long design session for work we will be starting imminently. Since this work has an initial delivery deadline, a constant theme of our discussions was how much to do “now” (before the deadline) vs how much to put off until “later” (after the deadline). Some of us grumbled that we really needed more time to be able to implement a better/proper design. As it is, we have to implement our changes in “design increments” which match our delivery schedule. From a design perspective, using design increments is definitely the harder approach.

It occurred to me that Darwinism doesn’t have the opportunity to implement a better design by either complete designs or intermediate design increments. Every small change must prove itself immediately and carry its own weight, otherwise it will be selected away. This is definitely the hardest approach — by a long shot.

Thank heavens that we software designers do not have to work with such Darwinian constraints! Large architectural changes would be virtually impossible to make. At best, making major architectural changes one small self-supporting step at a time would take an immensely long time!

A software development approach known as “Agile” (a lighter-weight process which is presumably more effective and more efficient) encourages a test-driven approach where every corner of the system is constantly being tested. If any of these tests identify an error, it can quickly be “selected” out (by applying the effort of an intelligent agent to fix the problem). Even in an environment where intelligent agents are constantly designing and implementing changes, natural (ok, maybe artificial) selection via test-driven development still has its place.

Software development is an activity of almost constant design. Implementation of software (known as “programming”) although normally not considered part of the “software design” process, is really just design at a very fine level. Software developers are therefore designing constantly! I think it would be fascinating to compare the constant design activity software development process with its Darwinian counterpart, which, ostensibly, produces output of comparable (actually, substantially greater) complexity and quality.

Interestingly enough, the creator of Linux once compared the Linux open-source development process of many contributors adding to the software baseline with the process of evolution (Linus Says, Linux Not Designed; It Never Was). That comparison, though pretty lose, does capture the idea of having many programmers trying out many solutions to a programming problem, with the “fittest” one surviving. Maybe evolution did happen that way: many individual designers competing for the best solution.

I think there is food for thought here. Software engineers are among those professions which are constantly engaged in design. One would think their experience on what activities can produce “the appearance of design” (and the difficulty with which a “quality” design can be produced) would shed some light on the feasibility of the Darwinian model.