I've been invited to present a talk on the Physics of Software at DDD Europe 2016. 

That caught me by surprise and I do not have any material ready for the talk, which could be a good thing (it's a chance to present fresh contents). I'm taking this opportunity to tune the talk with a small group of people interested in this line of work.

I've set up a trello board with the talk outline and I'll be recording the talk + slides in 10min installments (so let's say 4-5 for a standard 45min talk). More details in the trello board, but I'm interested in your feedback on both the outline and the contents. Both the board and the videos are private, because I like the idea that participants will see something new that hasn't circulated before.

Wanna help? Here is how:

- You need some familiarity with my work on the physics of software. 

- While I'm open to criticism on both the work itself and the presentation, I'm looking for feedback on the latter based on the premise that there is some value on the overall idea (otherwise, why do a presentation at all :-).

- You need a little time to look through the contents in trello, watch the videos, tell me what you think. Ideally, sharing feedback on trello will allow others to comment, but private feedback is fine anyway. If you have time to follow the discussion on trello and contribute, you're welcome. I don't expect this to turn into a high-traffic discussion anyway :-).

- It will take some time for me to complete the presentation, record vides, etc. So far I've recorded the most "technical" part, which is about 1/4 of the whole thing. So expect this process to extend for a couple of months.

- Ready? Get in touch via email or twitter to get an invite to the trello board (you will need a trello account, which is free of course). If we never had a chance to talk before (real life, twitter, blog, email, ...) a link to your twitter profile / blog / website / whatever would be highly appreciated.

Thanks for your help!

Many non-functional properties denote a potential. Reusability indicates a potential for reuse. That potential is fulfilled when we actually reuse an artifact. Information hiding indicates the potential to change a design decision without impacting other modules. It is fulfilled when you actually change that decision. Even readability indicates a potential. It is fulfilled when someone actually goes in and reads the code.

Suppose that you have some code in a stable (working) state X. However, that code is lacking some non-functional property, say extendibility in a specific area. From the perspective above, what you want is to move it into another stable (working) state Y with a higher potential. As usual, that won't come for free: you need to apply some energy (work) to change the state of your code.

Borrowing a page from chemistry, we can see a similarity with the notion of activation energy: "the minimum energy that must be input to a chemical system with potential reactants to cause a chemical reaction [...] Activation energy can be thought of as the height of the potential barrier (sometimes called the energy barrier) separating two minima of potential energy".

In a picture:

Here we have two stable states X and Y, which differ in potential by DH, but the activation energy, indicated there with Ea(X->Y), is higher than DH. 
The fact that activation energy (the energy you actually need to add to the system to move it from X to Y) is higher than the mere difference in potentials is commonly experienced in software design / development. Every time you see the possibility of a change that would increase some non-functional property, but decide not to pursue it because the effort may not pay off, you're experiencing a case where Ea >> DH. 

Of course, software is different from chemistry, because the dynamics of information are not exactly the same as the dynamics of matter. For instance, once you move to an higher potential state (say, reusability) you can benefit from that many times over, therefore balancing the initial investment. Still, a significant difference between Ea and DH may easily stop us from moving our code to Y, as Y is often just a potential. A lot of engineering common sense is merely pointing out these facts.

One of the niceties of writing software in the 21st century is that many languages come with decent development tools, which include more or less advanced support for automatic refactoring. Being able to select a portion of code and move into a new method, with all parameters figured out by a tool, or to automatically abstract some methods into an interface, etc., all lower the human effort (energy) required to move from state X to state Y. In chemistry, this is the role traditionally played by a catalyst; the purpose of a catalyst is exactly to lower the activation energy, as you see here:

Some language features act themselves as catalysts. Unlike many younger programmers, I learnt functional programming before object oriented programming. Lambdas and higher level functions were my bread and butter. In my first OO language (Smalltalk) I could still pass around code fragments with ease (as I always tell people, if is a method in Smalltalk, taking two code fragments as parameters). But when I moved to C++ and Java, I always missed lambda functions (until recently). 
Of course, there is nothing you can do with lambdas that you can't do with an interface, an implementation, and polymorphism. But the activation energy is quite high, and people tend to go with the "lower resistance path" (that is, stay with the lower potential, which in many cases means less information hiding here). In fact, the anonymous inner class idiom in Java was meant as a mild catalyst, but lambdas are way more effective as catalysts.

A dynamic language tends to lower the overall activation energy for most reactions as well. Which brings me to the conclusion for this short entry: although I have shown only one direction, reactions go both ways. You can move from a higher potential to a lower potential. You can mess up your code, so it still works (state X is stable) but it no longer possess some non-functional property you had in Y. 

A catalyst may lower activation energy both ways, from X to Y or from Y to X. It's easier to make a non-functional mess in a dynamic language, because implicit contracts make many non-functional properties hard to see. Lambdas, although extremely convenient, may prevent a bunch of functions to coalesce into new, meaningful abstractions (a richer interface), which is instead split into single pieces. Acknowledging this duality is part of a deeper understanding of things, and a good antidote to the superiority complex that comes with so many languages and paradigms.

Notes
[1] The pictures above have been adapted from a work in wikimedia commons, which license allows unrestricted use, including modifications.

[2] I wish I could say that I know how to put numbers on Ea and DH. I'm very far from there.

An interesting intuition from D'Arcy Wentworth Thompson [On Growth and Form; I read the 1942 edition] is that the current shape of an organism or artifact is a byproduct and in a sense a mirror of the forces that were applied during its growth (or construction). Something is flat because it has been pressed into that shape, or cut into that shape. This may seem trivial, but allows for some interesting speculation about the original forces by looking at the current shape.

While thinking about software, I came to a larger conclusion, which may seem equally trivial, but that I feel may hold the key to a more precise formalization of many notions. The shape and material of an artifact are also a recipe for its future reactions to forces. A long beam will bend easily. A wooden table will scratch easily.

When you move into the realm of programming and artifacts, things get interesting, because a recipe is in itself a set of pre-encoded instructions. So, when you consider a software artifact (a class, a function, etc) you see that the artifacts encode:

- a set of explicit instructions for the "essential interpreter", the machine that will execute those instructions. This is what we normally call "the function" or "the behavior" of that code. Those instructions are explicit in the sense that they are directly expressed in the programming language; using poor old C, which is close to the machine, I can say:

int f( int x ) { return x + 1 ; } 

and that means "dear computer, please add 1 to this integer x and return the result".

- a set of implicit instructions for the "contingent interpreter" of change, encoded in the shape of code. This may sound like intellectual mumbo-jumbo, so let's ignore the essential / contingent terminology (which I've borrowed from Richard Gabriel [Form & Function in Software]) for a moment and focus on the notion instead. 
Just like a physical artifact pre-encodes a set of responses to forces, so does our software artifact. Those responses are pre-encoded in its form. That's a rather powerful notion. 
If you look at f, its pre-encoded response to change is rather simple:
  - if you want to use another type instead of int, you either change f (and lose the version working on int) or clone f / change the clone.
  - if you want to add another value instead of 1, you either change f or clone f / change the clone or add a parameter to f.
  - if you want a different algorithm you may just as well implement another function and avoid bothering about transforming f (e.g. to take another function as a parameter), as f is too simple to be worthy.

If I switch to C++, I can say

template< typename T > T g( T x ) { return x + 1 ; }

the pre-encoded reaction to change for g is slightly different, as it basically says:

- it's like f, but you can use it for any type for which "+ 1" makes sense at compile time. So if your change is from int to one of those types, the reaction is that no change to g is necessary (damping).

Of course I can also write:

template< typename T > T h( T x, T y ) { return x + y ; }

and this pre-encodes another slightly different reaction to changes. Or move to:

template< typename T1,  typename T2, typename T3> 
  T3 r( T1 x, T2 y ) { return x + y ; }

and that encodes yet another reaction to changes, even though they would all return the same value when used with an integer and (if necessary) a 1.

Now, if you review a number of programming / design notions from this perspective (OO polymorphism, genericity, etc), you'll see how shaping software in a specific way becomes less and less about "respecting some principle" and more and more about pre-encoding a reaction to change (in the decision space). That's basically another program, which might or might not be executed. 
Most likely, that program won't be executed by a computer: it will be executed by a human, the moment those changes will become necessary. But in a sense, that's completely irrelevant. When you code, you're giving a set of instructions to the essential intepreter (the computer) and a set of programs (*) to the contingent intepreter (the future bearer of change). The first is directly encoded in the instructions, the latter is indirectly encoded into the form (shape).

(*) it's a set of programs, not a set of instructions, because it's up to the contingent interpreter to choose the program among those pre-encoded in the shape of the artifact.