Imagine software components that could adapt to each other and dynamically elaborate and fine-tune the protocol(s) they would like to use in order to collaborate. Imagine that we could actually develop pieces of software that would be smart enough to discover the presence (or absence) of well-known patterns in an environment thereby enabling them to participate in the collaboration governed by the newly discovered patterns. Even though some of you will say that many research dollars have been (and are still being) spent on this topic and that not much has come out of the labs yet, I have to believe that something cool and promising will come out in the future.

In Jaron Lanier’s opinion, in order to attain the goals mentioned above, we have to rethink the way we develop software. Lanier coined the expression "phenotropic computing" for qualifying this new kind of software.

In the previous part of this odyssey, I stated that the way we develop software today is doomed to fail because current software engineering technologies (processes, methodologies, programming and modeling languages et al) don’t let us cope well with the ever-increasing complexity of existing and future software systems. As Lanier said in his interview,

I completely agree with his first sentence, but not with the second as I’m not really sure there is any "long-range faith" that has ever driven computer sciences so far. However, I think that this is rather legitimate as the software engineering area is one of the youngest of all engineering domains. Even though it is one of the most rapidly evolving engineering area, it still needs to mature quite a lot. Apart from that, I think we all agree that we have to come up with new ideas to make software become fundamentally better. In order to achieve this, we have stop for a second and think about how we would like to develop software tomorrow. Today, when we talk about developing software, we almost directly think of it in terms of code. This is pretty normal as the code is pretty much all we have to comprehend and reason about the behavior of a software system and at the end of the day this is more or less what you feed into the compiler to build your system. According to this, some people will argue that the design of their software is fully contained within the code. While this is correct to a certain extent, this is a very dangerous statement as the design should offer a much more abstract view of the software than the code does. Moreover, there are plenty of things that we cannot express in code and that are better specified somewhere else. The only reason why I would agree to this idea (i.e., the code is part of the design) is that today we dramatically lack techniques for accurately synchronizing design and code and that we have to somehow build our system one way or the other even if we don’t have the right tools. This is really sad, but I’m pretty sure many people do actually manage the design of their software at the code level. Still, I’m really not convinced that their approach can be effective for any software systems whose code base grows over, say, 50’000 LOC.