Tuesday, February 17, 2009

More thoughts on the viability of evolutionary computation

I thought a little bit about the viability of using evolutionary computation in the field. That is, using Darwinian principles to design software.

In my writeup of Richard Gabriel's presentation to OTUG, I speculated that using evolutionary design may be a natural extension to the working specification or Test Driven Development principles. Essentially, if a specification can be provided in terms that can be fed into an evolutionary development environment, then the implementation can be left to evolution.

The downside to using evolutionary computation to implement our software is that not many humans may intimately understand how the implementation works. I began to think about how different letting a computer implement our designs is versus what many companies are doing with offshore development.

The model of offshore software development with many companies is to keep the architects and high level designing engineers stateside and send the work in the trenches overseas, i.e., all the finer grained detail work. I believe that many organizations that adopt this type of model are naive in thinking that it will simply work without a significant investment in establishing communication protocols between the high level designers and the people responsible for actually implementing the software.

The designers become an intermediary between the business/business analysts and the implementing engineers. The high level engineers take the requirements from the customers and give them to the engineers. They rely on their ability to communicate those requirements. Their people skills if you will.

The pitfall that friends of mine have encountered when trying to operate as the designer/intermediary reads like a Threes Company episode, i.e., breakdowns in communication cause considerable problems that seem to get discovered so late in the product development cycle that they require either a heroic effort to keep the project on schedule or they cause delays in the product's release.

People complain about the code coming from India being sloppy and difficult to read. It is clear that little attention is paid to considerations, such as future maintenance. Much of this I believe is due to cultural differences between Americans and the people who are hired to write software.

One must question the reasons why an offshore model of software development is implemented. Some organizations do this because sufficient qualified domestic help is unavailable. Company's are trying to save money by shipping work to a cheaper place. That's the theory, but the practice is wrought with more hidden costs and difficulties that often make offshoring more expensive than just doing the work in-house.

If the motivation is having cheaper workers regardless of the added burden and workload of the senior people in house, one should consider the difference between the added workload of the architects and high level designers and specifying the program parameters to a computer to design the software.

If the difference between specifying the acceptance criteria to a program is not sufficiently more expensive than specifying the acceptance criteria to a team of developers on the other side of the globe.

Given sufficient specification and evolutionary cycles, the resulting software will outperform the software that is developed by any human designer.

I think the next step in evolutionary computation is a system whereby human designers specify an interface and behavior and fitness model for software components, and the computer figures out how to meet those specifications as closely to the specification as possible.

Letting a computer handle class implementations, or even class level optimizations, seems like a natural progression from the current state of software development. Consider the level of abstraction that object oriented development and programming in domain specific languages has taken us. We're already trusting much of the implementation to the computers. It only makes sense to push the bar and see what we can do with another level.

No comments: