Monday, February 2, 2009

Chaos

In his book, Object-Oriented Analysis and Design, Grady Booch relays this story; "A Physician, a civil engineer, and a computer scientist were arguing about the worlds oldest profession. The physician says that the Bible recounts how God created Eve from one of Adam's ribs - certainly the work of a surgeon. Therefore surgery is the worlds oldest profession. The civil engineer explains that before Adam or Eve, God created the heavens and the Earth from chaos. Therefore, engineering was certainly older than surgery. The computer scientist simply asks, so where do you think chaos came from?"

Fred Brooks of Mythical Man-Month fame, wrote in No Silver Bullet, that the complexity of software is an essential property rather than an accidental one, and that this stems from four elements:
  • The complexity of the problem domain
  • The complexity of the development process
  • The flexibility of software (i.e. it allows for the introduction of more complexity)
  • The difficulty in understanding discrete systems (binary computers are discrete systems)

It is no wonder then that computer scientists, programmers, and IT professional believe they are employed in the worlds oldest profession as creators of chaos. Even if we allow the demons of our nature to suggest that creating chaos is the second oldest profession, we're still along way from noble endeavors. I suppose that doing something well, anything, is to be commended, but inserting complexity, disruption, unpredictability, and insanity into a perfectly useless Phantom Zone is enough to depress Clark Kent - Kal-EL as his friends call him.

Booch expresses the philosophy that programmers, computer scientists, and IT professionals are tasked with engineering the illusion of simplicity. Apple introduced the iPod on August 23, 2001, and made the task of buying, downloading, and listening to digital music easy enough for the masses. Unbeknownst to most people is that Apple used 200 lawyers to sift through the complex litigation required to make "Point, click, $0.99, download, unplug, play" actually work. And that doesn't count the complexity of the software itself.

Whether you're building an application, a network, a server, a transaction or any other complex digital solution, the task at hand is to make it work every time as expected, a.k.a. the illusion of simplicity. There is one key to systems that just can't fail - reducing the size of each element to a manageable unit. I'll forgo the description of how this fit into the four pillars of object oriented design (abstraction, inheritance, encapsulation, and polymorphism), and just focus on the benefits of this one concept.

So here's a trick question; how do you write a thousand line program with zero errors. Answer; you can't, but you can write a ten line program without errors. In fact you can write a ten line program that is so blindingly simple it cannot fail. If you do that ten times, and then do that ten times, you've got your thousand line application that cannot fail. I used to teach programmers that if any single function/method/sub-routine had more lines than could fit on one screen, it was too complicated to understand, document, or debug. You have to make each deliverable a manageable unit.

Starting in the 1990's the Standish Group produced research cleverly titled the Chaos Report. It showed that 31% of all IT projects worldwide are considered failures before they are done, another 53% are considered failures within a year of completion, with the remaining 16% being successful. Over the years there have been improvements in these percentages with the number one contributing factor to improved IT project success being a reduction in project size. The use of iterative methodologies such as eXtreme, Agile and SCRUM allowed project managers, developers, testers, and analysts to grasp the entirety of an objective - and thus deliver better results. Smaller things are more easily managed. Making big things out of reliable small things results in reliable big things.

Whether you are building an application, a network, a server, a transaction or a complex multifaceted system, you need to construct it with small, impossible to fail components. One of the hidden tricks to doing this (the 'this'; is building impossible to fail micro-systems) of course is that it is easy to catch errors when the system is very small. A small system can only fail in a limited number of ways - handle all of them, even if that means passing the failure up or down the system. Make sure that each upstream and downstream component that might receive an error deals with it appropriately. This task is considerably easier when the components you're building are very small.

The result is a system comprised of components that cannot fail, and thus a total system which is reliable. The illusion of simplicity is the result of building complex solutions from highly reliable micro-systems, often through an iterative development process using small teams.

No comments:

Post a Comment

Follow by Email