In my previous posts, I discussed the concepts of non-random selection and arms races. With this understanding in mind, we can start to see a very important concept arise.

 

Accurately defining the unit of selection is absolutely critical to effectively evolving your software.

 

It is all too easy to introduce pleiotropy into software. Pleiotropy in biology is the ability for a single gene to cause multiple phenotypes. For example, some cats have a particular allele which makes them white, and they also happen to be deaf. Other alleles may cause changes in the face, ears, and hair - all from a single gene. In software, this principle generally expresses itself as unintended consequences - generally these are bugs.

 

Once we put these two concepts together, we gain some very important architectural learning, which will come as no surprise whatsoever to any software engineer: you want to design your software so that modification to one system do not adversely produce unintended side effects. While it seems quite obvious, it is not always that straightforward to execute on this.

 

Furthermore, you would also like to architect your system to enable you to select into the next generation of your software those implementations which have given your software an evolutionary advantage, while mutating those elements of your system which have not given your software the competitive advantage you had hoped for.

 

A highly visible illustration of this notion comes with the separation of user interface from business action. This is a pattern that has been around for quite some time, most commonly known as model-view-controller. As the user interface is something that is highly likely to change (this is the component that is most visible to the user, and tastes tend to change over time), you would like to be able to select those UI elements which make your software easy to use, while mutating those that are not comprehensible enough to surface a given functionality. Nonetheless, it is very common to see many logical dependencies sitting inside of UI code. How many web development projects on ASP.NET, for example, have you seen with business logic code sitting in the code-behind for a given page? How many button handlers in a Windows Forms application immediately take some action right inside of a form user interface object?

 

Once you begin thinking of your software with the goal of explicitly defining your units of selection, you can begin to architect your solution to achieve this goal.

 

As an example, consider the architectural changes being undertaken for Windows Vista. Larry Osterman provides a description of this layered architecture here. In essence, what the Windows team has created is a system of layers wherein components in a given layer should not have a dependency on components in a higher layer. The lower a component lives in this layered system, the higher the probability of pleiotropy. As a result, low level components have been set up to evolve slowly and deliberately, as changes will involve extensive testing of all higher-layer components. Components that sit in a high layer are now able to evolve far more quickly, because there is a much smaller chance of pleiotropy in these components. Not only can they do so, but there is an implicit statement that they both want and expect to do so.

 

This is an appropriate starting point to architecting your software to evolve - explicitly defining those components which can be rapidly evolved. And, in any reasonably complex software project, this is an important statement to make, and it should be explicit.