In my previous post on complexity, I outlined some of the perils that can result from increasingly complex software. For part deux, we’ll examine a solution to the complexity problem.

One fundamental aspect of software development must be remembered during any conversation regarding the problems of software complexity: good software arises out of a process of gradual refinement. This simple premise is often overlooked by the stakeholders involved in a project (including developers). However, a single word has arisen out of the programmers’ lexicon into the mainstream that tersely communicates the state of a project currently undergoing some form of refinement: Beta. Beta is a powerful word. Beta communicates to the end-user (and client) that the application they are currently using has not yet reached its full potential.

Beta means different things for different applications. For some, Beta means that the application either has functionality that may not work at all under certain conditions, or that obvious functional points are missing but will soon be in place. In other words, it’s a means of providing coverage when things go wrong or when things are obviously missing. For Google’s increasingly popular GMail, Beta means “100% of the functionality we have provided will work 98% of the time, but there are many wonderful things we have in store for you that we will present on our terms.” It is thanks to Google, I think, that “Beta” has become an almost everyday word.

It is also thanks to Google that the process of gradual refinement in software, a process programmers call Iterative Development, can be packaged as a more palatable concept for stakeholders who drive software production (e.g. our clients at Spunlogic). Any application that contains an easily-identifiable amount of complexity (in either concept or execution) must go through an interim Beta phase until the project’s goal or the client’s vision has been met. Of course for large and complex projects, vision may be clouded from the outset. This provides all the more reason to develop and launch the project in iterative steps, refining the application while at the same time refining project goals when necessary. As more pieces of the application are launched, stakeholders can protect themselves from the storm of complexity by keeping the application under the “Beta umbrella.”

I’d like to return to Google and one of their flagship products, Google Maps, as an example of iterative development done right. Google Maps currently provides the means to view satellite data of a region with a road-map overlay, view real-time traffic data in major metropolitan areas, view building elevation in these areas, re-route driving directions via drag-and-drop interaction, etc., etc., across multiple countries. However, when Google Maps first launched, it did two things: provided driving directions (and not always reliable ones) on a slick drag-able street map view of the United States. Here are some highlights in Google Maps’ iterative evolution from a product that delivered two main pieces of functionality for one part of the world to a product that can do dozens of different things while representing many places across the globe (with credit to Wikipedia):

• February 8 2005: Google Maps first announced, providing street maps and driving directions covering much of the United States.
• Late June 2005: Google releases the Extensibility and Customisation API, laying the foundation for the Google Maps Mashup movement.
• Mid July 2005: Google releases Google Maps for Japan.
• January 2, 2006: Google Maps features road maps for the United States, Puerto Rico, Canada, the United Kingdom, Japan, and certain cities in the Republic of Ireland.
• On April 3, 2006: version 2 of the Maps API is released. Two months later, geocoding capabilities are added.
• February 2007: buildings and subway stops are displayed in Google Maps “map view” for parts of New York City, Washington, D.C., London, San Francisco. MARTA stops have since been added.
• February 28, 2007: Traffic information is officially launched to automatically include real-time traffic flow conditions for 30 major cities of the United States.
• May 30, 2007: Street View is added, providing a ground-level 360 degree view of streets in some major cities in United States.
• June 28, 2007: drag-able driving directions are introduced.
• November 27, 2007: “Terrain” view showing basic topographic features are added.

Obviously, Google Maps has become an extraordinarily complex application, and not all applications must deliver this degree of complexity. Regardless, the Google Maps development life cycle is a case-study in how to mitigate complexity through iterative development.

Assume that some of the great functionality present in the current iteration of Google Maps was not foreseen at the outset of the project, but grew organically from within the development process. At the same time, there must have been some functionality on the drawing-board that never made it out of iterative development (and certain things that did make it out have since been iteratively eliminated, like the “Hybrid” view). All the while, Google Maps lived in a Beta state throughout much of its life (it is no longer Beta).

We must take this model and apply it to our own complex projects. A Beta site launch will portend a better product for all stakeholders and iterative development will help solidify the product and eliminate distractions to the project goal.