Genetics

From APIDesign

Current revision

The Genetics of an APIDesign is an interesting topic that recently came up when I was trying to use the Evolution vs. Intelligent design argument among my colleagues. It is a paradox of APIDesign - if you are a regular software architect you can act as an Intelligent designer and many successfully do. You have the vision and you may strive for it.

However, when you are an API designer, you'd rather worship evolution - your goal is to create a system that others use to do something intelligent, but you, as the API architect, don't set the ultimate goal. A key to success is to create a system that blossoms with evolution rather than prescribing what shall be the result.

The puzzle to gain more insight into the difference between these two approaches starts with a thought: The core concept of evolution is pretty much copy an existing thing with only minor modifications!

Copying Genes vs. Species

In order to practice evolution the nature allows copying, mixing and even random errors when producing new instances of the creatures. The creatures differ slightly then, while remaining capable to deal with each other and compete to become the best survivors and produce new copies of themselves. However that only works if the modifications are minor!

If you triplicate human 21st chromosome you get people affected by Down syndrom which isn't lethal, but significantly shortens the expected lifetime and decreases/if not disables the ability to reproduce. If you mix a donkey with a female horse you get a mule - while mule is useful and mankind even deliberately plants them, it is no good from the point of genetics - it can no longer participate in evolution and reproduce further.

Doing major copying changes may have some short term benefits, but it is a dead-end from evolution perspective.

Very likely we can go even further - if you copy just fifteen human chromosomes to produce a creature that can actually live - will it be able to participate in the evolution of humans? Unlikely. If it is able to evolve at all, it is going to become completely new species. The evolution will only be possible in the isolated species - mixing and sharing achievements between the original and the new species will not be possible.

May it be God's will? Maybe, but it clearly shows the difference between minor change and a major change when making a copy!

Copying In House

APIs are like Stars and there is a difference between designing a house and a Universe!

You have probably seen thousands of successful applications of the copying when developing an in-house software. Be it quick sort code you copied from StackOverFlow website or some Open source library you rather copied to not have to do with legal implications of its license.

There are companies building their business on copying OpenJDK and shipping it with minor modifications - for example with a better Garbage Collection algorithm or better final tier compiler. It does work. What can be the conclusion?

We have seen it working! Let's repeat the previous success! Again and again ... until we find out it doesn't work in the Universe of APIs!

C#/.Net vs. Android

At the end of last century Microsoft abandoned Java due to lawsuit with Sun. However, as the promise of Java was really huge, Microsoft decided to create its own copy called CSharp. Clearly inspired by the Java concepts and while fixing some of the Java problems, it even become nicknamed Java 2.0. Where's CSharp now? I don't know and I don't care!

Java and CSharp become its own species without any common ground. From time to time they influence each other with ideas (there is JUnit and NUnit or Ant and NAnt), but they never straighten each other. Attempts to make a language like Scala compile to Java bytecode as well as CSharp's one died out. The copy was so major that - while it gained some traction initially - it matters less and less.

Android, as introduced in 2008, is a completely different beast. While different, it could run Java programs since the beginning. Not every library was ready for Android, but adjusting them to run on both systems - HotSpot and Android - was possible and after few years all major libraries and frameworks could run on both. Since then the ecosystems straighten each other. Android Studio - the official tooling for Android fuels tooling for the whole Java ecosystem. Kotlin language (introduced to mitigate possible damage of Google vs. Oracle lawsuit) is becoming more and more popular in non-Android space as well. Android gained a significant advantage because it looked like, behaved and really worked as a minor copy of Java.

Copying APIs vs. Species

If you want your copy or rather re-implementation of some APIs to participate in overall ecosystem and truly benefit from previous as well as future evolution, you have to copy just the implementation - not the APIs. The API - e.g. the facade - has to remain the same. People need to be able to write one code and interact with both creatures. In the genetics allegory - you want to invent new color of an eye, but not a third eye and excommunicate own-self from the existing species. Staying in the existing species is what evolution likes. At the end it may even bring you more benefits like better tooling, new languages, more libraries, etc.

If you copy the API ideas instead and create own species from a scratch, you are likely to end up like CSharp - useful, but always second - intelligently designed but only of interest by a single designer and its gang!

Genetics of an APIDesign

API is what defines a species! Different implementations or users of the API are then creatures that evolve together and straighten each other! APIs shall not be copied, but only re-implemented. That's the paradox of copying an API!