This is the first episode in a series of posts reviewing the first Global Software Architecture Summit that took place in Barcelona the 10th of October. To see the whole list of episodes, please visit this.
Code is your partner in thought
George Fairbanks (@Fairbanks) was the first speaker, and introduced to us some ideas which originally appeared in a book by Peter Naur, in 1985, being the most relevant of them the realization that the act of Programming, understood as the overall set of activities involved in the production of software, is by itself a task of invention of theories to understand a problem and finding suitable solutions to address it. Actually, the title of the Naur’s book was “Programming as Theory building“.
To achieve a solution to a given problem, we first invent theories, and the code we eventually write is a representation of that theory. Which is another powerful reason why the code must be as understandable as possible: because the code is the main instrument of communication of that theory to other people, now and in the coming future; a purpose, by the way, that the old-fashioned procedure of writing tidy documentation upfront of the code was unable to fulfill ever.
Computer programs only make sense to the team who have developed it
Peter Naur (1985)
In other words, the code repository is not only where the documentation of the solution, and of the problem it addresses, live. Since that code is also a representation of the theory we invented in the process of understanding the problem and generating ideas to handle it, git is not only in charge of handling a repository of code, but also a repository of knowledge.
Actually, this is an idea which stands out as the pivotal summary of the whole event: the creation of software is an exploration of thoughts inspired by the necessity to address some problem, and it looks, and it should be practiced, more as Science is, via the scientific method. Come up with an idea, produce some experiments to test it, and, if the experiment ends well, make it happen in Production, just before keeping the exploration going on.
Even more, this procedure of coming up with a theory, test it in practice, and eventually put it into production in the form of runnable software, is a long term learning process. As metaphor, we might imagine a wider cycle around the quicker Agile cycles that we are used to call sprints: a process extremely important, in my opinion, to keep Scrum teams from falling to the sickness of delivering new features time and again, but never reaching any goal.
Fairbanks dropped other interesting thoughts, as the concept of the Model-code gap (in essence, the troubles which arise whenever the representation of our thoughts that we put in our code is crooked, or biased, instead of the finest match to them possible), or that documentation is a good place to explain those ideas or decisions which did not get through: precisely because the code does not represent them, it may be a good practice to include them in the code repo as README files, for instance.
In essence, it was a very nice introduction of the main topics that we were going to see showing up throughout the whole event.
Copyright notice: Painted portrait of Peter Naur by Duo Duo Zhuang.
how possible 