Evolution: The Fittest and the Sexiest

The topic of this blog is "SOA Evolution" so it seems overdue for me to look at the Evolution process. I coined this title to chronicle my organisation's slow but deliberate adoption of SOA. 'Evolution' seemed to be an appropriate term because it was both a slow process but one that would improve our applications. In this posting I will look at evolution more literally and find more appropriateness in the term than I first imagined.

I am reading a book by Richard Dawkins (see references below) on a range of topics but primary about evolution in biology. There are two principal evolutionary processes. One is the survival of the fittest and the other is sexual selection which is the process of influencing the evolution process by the choice of a mate. The success of evolution is its ability to adapt to its environment and to succeed against other species in that environment.

Natural adaptations are gradual and based on the parent life form. The history of the life forms can be discerned in the DNA of the life form. We can determine that humans evolved from an ancestor we share with Chimpanzees from looking at this DNA.

The process of survival of the fittest can be applied to software development technologies. We see various versions of programming languages replaced by later more effective versions. We see whole languages disappear into obscurity (eg. Algol, APL, SmallTalk, ADA) or replaced by new languages. Relational databases took over from set-based or network databases. Software development approaches have evolved from structured programming, to object-oriented programming to SOA. It has been mentioned that SOA was forged from marriage of distributed computing and document-based integration.

Extinction of old approaches is often not as complete as we would like. The Cobol programs and the old database technologies are still around. The old dinosaurs are hard to kill off completely.

As with any evolutionary process the origins of software development are evident when we dig deep. Visual Basic .NET is still saddled with some of the terminology and constructs that were around in DOS Basic. The kernel of some operating systems still contains some anachronisms which would not be used if it were not for historical reasons. Many software systems have parts that were written long ago or copied from other systems that no-one can maintain or just do not make sense in the context of software written today. Some software maintenance tasks are like archaeological expeditions. Unfortunately it is not passive fossils that the software archaeologist finds amongst the code. Some of these historical curiosities actually support critical business functions.

There are some principles from long ago that we do not want to discard though. Just like some of the primitive instincts and emotions buried in the core of our brain there are principles from long ago that should remain in our software. Procedures and functions still have a role in our software as do objects. The development of services does not replace the need for these other means of encapsulation. The principles for strong typing and structured programming still have as much value today as they did thirty years ago.

The mechanism for natural selection process in software technologies is not that different from the animal kingdom. Programmers will rewrite software using new techniques if requirements change. New tools outsell older tools that do not provide the same benefits. New techniques that reduce development time or improve quality replace old techniques.

Just as species become extinct old software technique die from disuse or replacement. Old code does not die off as quickly as some of us would like. It can last forever in our systems if the requirements it fulfils and infrastructure it uses do not shift too markedly.

Charles Darwin had two theories that he espoused in his books "The Origin of the Species" and "The Descent of Man". One could be paraphrased as 'survival of the fittest' and the other once was 'sexual selection'. Sexual selection is where a mate is selected because he or she is bigger, is stronger, is darker, has more colourful tail feathers or has less hair and therefore individuals with these characteristics tend to propagate.

I have briefly explained how the fittest software and development techniques succeed at the cost of inferior versions but it is also true that the sexiest software can be propagated despite any objective superiority. This can happen through good marketing or the support of a major company. Software standards are often agreed upon, even though they may not be the best based on an objective measure of quality. Often the benefit to adopt a standard exceeds the cost of the standard being suboptimal.

'Survival of the fittest' and 'sexual selection' are alive and well in the software industry. I expect SOA to remain an important part for the genetic makeup of future software development even after the term has lost its currency.

References

Dawkins, Richard, A Devil's Chaplain: Selected Essays, Phoenix 2003

Darwin, Charles, The Descent of Man, 1871, http://www.infidels.org/library/historical/charles_darwin/descent_of_man/

Darwin, Charles, The Origin of the Species, 1859, http://www.infidels.org/library/historical/charles_darwin/origin_of_species/

SOA Videos

I read a posting by Collin Smith which included some YouTube videos. This gave me the idea to do my own posting on SOA videos. This also gives me the opportunity to reuse my keywords 'Monkeys' and 'Lego' which so far I have only used once each. My most popular posting so far has been 'Chasers War on Wikipedia' which is more about entertainment than SOA. This posting may be similar.

First, here are some YouTube videos. They have obviously all come from the same source but I am not sure who takes the credit for these.

SOA is like Lego Blocks, http://www.youtube.com/watch?v=sbd_1G8Kqjs&eurl=http%3A%2F%2F
I have a previous posting on this analogy. Like other commentators for some reason they have not used real Lego blocks in the video. Instead they have used a pale imitation. At least they have called them 'Building Blocks' rather than 'Lego'.

SOA is like Music, http://www.youtube.com/watch?v=zV860odGN5Y
This fits with discussion on SOA orchestration but still does not do a lot for me.

SOA is like choosing what wear, http://www.youtube.com/watch?v=dyHWAiG6c-Y
This analogy took me by surprise and it does not really work for me, but the girl is pretty.

Greg the Architect, http://www.gregthearchitect.com/index.html
If you have not seen 'Greg the Architect' yet, then you are missing out. This is the pinnacle of SOA satire, even if it is the pinnacle of a very low heap. It is produced by the people at http://www.soanowjournal.com/. At the time of writing there are four episodes.

• Greg the Architect SOA
• Greg the Architect ROI
• Greg the Architect Focus Pocus
• Greg the Architect - Off the Grid

SOA Monkey, http://www.youtube.com/watch?v=cM31qu9T3Iw
This one appealed to me. It is seriously off the wall. This monkey knows a bit about SOA though.

The following videos are more informative than entertaining.

There are some good interviews with SOA people of note at http://tv.sys-con.com/read/category/1260.htm . These interviews have advertisements though. I liked one I found on YouTube with the advertising removed 'SOA Power Panel with Jeremy Geelan'. There were a couple of good things I got out of this hour long video. Firstly the quote "Think different. Don't think too long" and secondly eight service characteristics of SOA:

• Loose-Coupling
• Contracts
• Manageability
• Versioned
• Discoverable
• Addressable
• Distributed
• Point to Point (None of the speakers seemed to agree with this one)
• Self-Describing (This was a ninth one that was added by a speaker)

Tarrant County implements SOA for criminal justice agencies, http://www.youtube.com/watch?v=JIpLllGl1fc
This is advertising for Progress Software but I liked it because I work for a justice agency.

SOA - Service Oriented Architecture Introduction, http://www.youtube.com/watch?v=sRFwswaJpD0
This was a good SOA definition but turn down the sound because the speaker sounds like she is reading a children's story.

Another good source of SOA video is http://www.infoq.com/. I have mentioned these in earlier postings. In the posting 'ESB or not ESB?' I referenced some videos from Mark Richards (http://www.infoq.com/presentations/Enterprise-Service-Bus) and Sandy Carter (http://www.infoq.com/interviews/sandy-carter-soa). In 'AOP: The worst form of Coupling' I use Jim Webber's comments about MEST from http://www.infoq.com/news/2007/08/jim-webber-interview.

Sometimes after a hard day at the office reading pages of IT jargon I find the videos easier to absorb than more text information. I hope you can find something here that is either entertaining or informative.

Code Monkeys

In preparing for this blog I looked the the infinite monkey theorem on wikepedia (http://en.wikipedia.org/wiki/Infinite_monkey_theorem). It’s the theorem that goes "a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will type one of Shakespeare's great works. Apparently this was subject to a real experiment. The result was they discovered the monkey's continually typed the letter "S", defecated on the typewriters and did not produce any text of which the bard would have approved.

The relevance of the infinite monkey theorem to blogging is of course that if you keep on writing long enough at some point you might come up with something that is worth reading. This is my hope. Of course like the monkeys (and some other writers I know) I could end up getting very repetitive and using the keyboard for purposes for which it was not designed.

The term "Code Monkeys" is pretty objectionable. Writing code is difficult and exacting. If Shakespeare had to conform his works to the requirements of a compiler I suspect he would have had difficulties. Writing code no longer seems to be about sticking to the one language and submitting it to one big box that follows the instrutions. Now an application may spread over several layers using different languages and running on different boxes. This actually could be progress if it done properly. It should allow more agile, more integrated systems with more flexibility. Sometimes it is hard to convinced.

(The image of the monkey above is borrowed from a Zapthink presentation by Jason Bloomberg)