I was reading the above article this morning. The undercurrent of the article is that certain evolved systems grow in size while at the same time growing in efficiency. Examples are animals and cities. On the other hand, some systems grow in size while losing efficiency; not surprisingly, one example is mature companies.
My interpretation of the results was that strong evolutionary pressure, coupled with the continuous experiments in creative destruction are the prerequisites for growing a system that wont destroy itself in the long run.
There's also another type of system that tends to kill itself off as it grows; these are software systems and to counteract this tendency software engineers also introduce evolutionary pressure and creative destruction.
Unit tests are the technology that enables creative destruction, or refactoring in software talk. A lot of talk promotes unit tests as a way to cut down on defects. That's a lower level use of the technology. A far more important use is to allow an engineer to take existing code and rework the design to support change. Without units tests our only option for enhancing existing code is to kludge an addition in the safest looking place and hope we have understood all the side effects.
As for evolutionary pressures, software engineers often introduce those into systems they are working on in order to drive the creative destruction and force the systems they build to have superlinear (see the article above) growth characteristics.
Continuous deployment is a pressure that forces a system to evolve along the delivery axis. I have read that Paul Graham keeps track of lines of code as he develops his Arc language. He wants to create a succinct and expressive language and that's one metric that he uses to force his language to grow in fitness. The developers of project Oberon wanted a compiler that was both powerful and simple so they forced themselves to add functionality to their compiler while maintaining limits for self compilation speed and self compilation object size.
The Haskell language is also an evolutionary experiment with corresponding pressures. They wanted to see what software development innovations they could discover in an environment that would only allow functional, lazy programming techniques. Im sure that decision has forced many discoveries but one that I'm aware of is Haskell's use of Monads.
If we think about our own software efforts we can also think of places where we can apply evolutionary pressure to our systems. Making sure code passes automated checks like Checkstyle's metrics can help one to write code within complexity limits. Lines of code limits or a tool like Simian would be a way to force systems into simplicity and expressive power. Code coverage targets would encourage adaptability and robustness. Performance testing like JMeter forces software to maintain computing efficiency.
Tomorrow is a new week ---- what forces can you apply to your systems to force them onto a long term fitness curve.
Marco
My interpretation of the results was that strong evolutionary pressure, coupled with the continuous experiments in creative destruction are the prerequisites for growing a system that wont destroy itself in the long run.
There's also another type of system that tends to kill itself off as it grows; these are software systems and to counteract this tendency software engineers also introduce evolutionary pressure and creative destruction.
Unit tests are the technology that enables creative destruction, or refactoring in software talk. A lot of talk promotes unit tests as a way to cut down on defects. That's a lower level use of the technology. A far more important use is to allow an engineer to take existing code and rework the design to support change. Without units tests our only option for enhancing existing code is to kludge an addition in the safest looking place and hope we have understood all the side effects.
As for evolutionary pressures, software engineers often introduce those into systems they are working on in order to drive the creative destruction and force the systems they build to have superlinear (see the article above) growth characteristics.
Continuous deployment is a pressure that forces a system to evolve along the delivery axis. I have read that Paul Graham keeps track of lines of code as he develops his Arc language. He wants to create a succinct and expressive language and that's one metric that he uses to force his language to grow in fitness. The developers of project Oberon wanted a compiler that was both powerful and simple so they forced themselves to add functionality to their compiler while maintaining limits for self compilation speed and self compilation object size.
The Haskell language is also an evolutionary experiment with corresponding pressures. They wanted to see what software development innovations they could discover in an environment that would only allow functional, lazy programming techniques. Im sure that decision has forced many discoveries but one that I'm aware of is Haskell's use of Monads.
If we think about our own software efforts we can also think of places where we can apply evolutionary pressure to our systems. Making sure code passes automated checks like Checkstyle's metrics can help one to write code within complexity limits. Lines of code limits or a tool like Simian would be a way to force systems into simplicity and expressive power. Code coverage targets would encourage adaptability and robustness. Performance testing like JMeter forces software to maintain computing efficiency.
Tomorrow is a new week ---- what forces can you apply to your systems to force them onto a long term fitness curve.
Marco
RSS Feed