Coding formalities

Another holy war

Recently I was reading blog posts and heated forums discussions on what seems to be the latest flame war: Object Oriented vs Functional programming.

It was rather funny to read opinions ranging from "OOP considered harmful" to "FP is just a toy" but, after the amusement, I wondered if we can use this discussions to make a step forward.

Let's face it: we (as The Software Industry) are lagging behind. In all the past years we did not progress much in the way we develop our code.

Yes, we now have much better tools (our IDEs are a breeze to work in), we are more disciplined in the way we manage the development process (I remember one of my first project where version control was done on paper! I had to introduce the latest and greatest tool of that time for version control: RCS!), we have access to much higher abstract concepts but there's not much difference in how we write our programs.

Elephant on sight!

There is so much rage about this or that feature of a programming language but the elephant in the room, that everybody pretends not to see if this questions:

Are we getting better at ensuring our programs are correct?

There are many aspects of correctness but, basically, we should be interested in being confident that what we create is what it was intended and that it works in the way it is expected to work.

The elephant question has many sub-elephant questions: "Are we getting better at specifying what we want to develop?", "Are we getting better at ensuring that the system has still the same behaviour after we made the last change to the code?", etc. etc.

Formality

To me, it all has to do with formality, i.e. the ability to express precise and unambigous statements.

In the end the code we write is a formal system. It must abide to strict rule so that our wonderful computers can run it.

In contrast, our starting point is completely informal. We start with specifications like: "I want you to write a software that allows plumbers to compete in a go-kart race" and have to move forward until we create a good clone of a well-known videogame. Except that, in the end, we discover that we were expected to create a software to schedule and manage the results of go-kart races held by the local Plumber Association.

Our job as developers (a term that will include coders, architects, designers, analysts, ...) is to reduce this formality gap over time, until we'll release a "correct software".

It would be great if we could devise a formal method (i.e. an always precise and unambigous way) to express requirements and (within this formal system) refine them to the code but this is just impossible (I could invoke Gödel here but let's not digress). And even if it was, it would be extremely unpractical and undesirable.

So, what can we do to ensure that, at least, we are heading in the right direction?

Measuring formality

Quite some time ago, I came across an interesting article from professor Francis Heylighen about Formality and it struck me as spot on.

Following the thesis in the report, we can say that an expression is more and more formal if its meaning is less and less dependent on the context.

The formality of an expression can never be 100%. Even programming language statements like printf("Hello %s!\n",name); are dependent on the some context (namely, the fact that the programming language used is C) to be interpreted correctly.

However, the more context a group of people have in common, the easier is to have formal expressions whose meaning is unambigous (for that group of people).

The plumbers go-kart races above is a clear example. We assumed that the shared context between us was related to videogames, they assumed the shared context was the recreational activities of the Plumbers Associations. Different context, different meaning!

What is good?

We can use these concepts of formality and common context as a compass to see if we are heading in the right direction.

We can increase formality by adding tools, notations and processes that would remove "syntatical ambiguity" and we can increase the common context with the practices we use nowdays: User stories, Stand up meeting, Industry standards, ...

An example: "release early, release often" is good because it allows to add a formal object (the released functionality) to the common context so that it's easier to see if something had been left out until then!

An experiment: think about something you think is crucial for a successful development and let's see if we can describe with this two concepts.

The Focus

What we should focus on in our development process is that, at each step, the formality increases so that things are really progressing.

This means that each actor in the picture below should use the common background with the actor on his left to understand what needs to be done and use the common background he has with the actor at his right to describe what he understood.

Thinks go wrong when someone just ignores this fact; for example when an Analyst writes a User Story purely on his background with the Client without adding anything that is part of his common background with the Designer. The designer will most probably misunderstand or will have to go back asking for further clarification.

"What do you mean, "you didn't know a Plumber Association existed"? And who is this short Italian plumber with mustache?"

Back to the beginning

What has all this to do with the FP vs OOP flame war I talked about?
Very little. And that's the point!

At the very bottom we all have the same view of a program. It is:

• a state (represented by the value in a set of variables)
• a set of rules that specify how the state change

We use the variables to represent the chunk of reality we are interested in and specify the rules that will change those variables so that they will represent the evolution of a process.

So in the debate "OOP vs FP", the question for me are:

• which one helps me reasoning better about transition from on state to another? (increase of formality)
• which one helps me representing my reality at different level of abstractions in a consistent way? (ease of handling common context)
• which one will "shorten the lenght" from end user to the code? (reduce the need of multiple common contexts).

My answer is that they are roughly at the same level. One may be better in a situation, the other may be better in another situation but none of them solve the ineherent problems we face when creating a new application.

Conclusion

All this sounds very abstract, I know, but I think it has very deep practical impact.
Maybe what we need to move forward is some better common view that we can use as a context to increase the formality of our development process.

Don't know about you, but I feel now it's the time to focus on finding what could make us work substantially better, rather than spending time debating which fad of programming language is "better".