I'm trying to understand the lesson behind this result.
I don't think it's the obvious, well-understood fact that biological systems have massive, redundant parallelism, whereas our software systems do not.
I believe it in fact says something very specific and fairly non-intuitive: that biological systems have many slightly different copies of key routines, whereas our software systems as they are designed today do not.
"That’s why E. coli cannot afford generic components and has preserved an organization with highly specialized modules, said Gerstein, adding that over billions of years of evolution, such an organization has proven robust, protecting the organism from random damaging mutations."
For example, imagine instead of having one 'sort' function, you had different sort functions dispersed throughout every area of your code that performs sorting, and each one was very slightly optimized (through design or some unspecified evolutionary process) for the particular characteristics of the data being sorted at that program location.
Thus, 'sort' is no longer a single point of failure. If one of your sort routines has an exploitable buffer overflow, then it's probably the only one that does, which limits the potential damage to the system as a whole -- especially if you've designed your entire system this way.
Could it be better in some cases to copy and slightly modify a software component, than to simply reuse it?
It absolutely makes sense to make your fallbacks independent from one another, but implementing fallbacks at all is expensive.
In evolution, you're pretty much guaranteed a breakage at some point that can't be fixed.
That's not quite as true with software - you're still guaranteed breakages, but you get to fix them, and fixing dependent systems is a whole lot more economical.
I think the best analogy is interfaces. You code to an interface with multiple implementations, and if a problem occurs, you switch implementations. Next, if you have vulnerable and complex components, you make sure they each have a custom implementation, so the inevitable bugs can't be widely exploited.
I don't think it's the obvious, well-understood fact that biological systems have massive, redundant parallelism, whereas our software systems do not.
I believe it in fact says something very specific and fairly non-intuitive: that biological systems have many slightly different copies of key routines, whereas our software systems as they are designed today do not.
"That’s why E. coli cannot afford generic components and has preserved an organization with highly specialized modules, said Gerstein, adding that over billions of years of evolution, such an organization has proven robust, protecting the organism from random damaging mutations."
For example, imagine instead of having one 'sort' function, you had different sort functions dispersed throughout every area of your code that performs sorting, and each one was very slightly optimized (through design or some unspecified evolutionary process) for the particular characteristics of the data being sorted at that program location.
Thus, 'sort' is no longer a single point of failure. If one of your sort routines has an exploitable buffer overflow, then it's probably the only one that does, which limits the potential damage to the system as a whole -- especially if you've designed your entire system this way.
Could it be better in some cases to copy and slightly modify a software component, than to simply reuse it?