What I learned from Software development when I built my house

The day the workers finally left the work and I could properly call it “home”, I noticed with astonishment that my body and my mind experienced the same fatigue that is familiar to the days after a sacrificial and demanding deadline. The satisfaction of the conclusion and the confirmation of the effort.

This coincidence and the repeated conversations, hand in hand with the difficulties we managed to overcome with Gustavo — the bricklayer / architect who carried out the construction — gave rise to this reflection that, humbly, I consider useful in my demystifying crusade of what can be done. understand how the development of Software.

The first thing is that context is everything.
Or almost.

The skills of a country house that lacks an aqueduct and sewage system or domestic gas network, are abysmally different from those of a work that makes its way into a traditional neighborhood of a densely populated city.
Like everything, what in one circumstance is an advantage, in another totally different, is a complication. Thus, the conditions provided by the context are not inherently better or worse than others.

According to the case and who decides to advance the work, it is possible to establish subjective criteria to prefer one context over another — criteria, once again, as all, debatable.

Spinning deeper as far as software development is concerned, context is synonymous with coupling. And just as every day the number of public and private services that integrate works in highly coupled cities increases, it is no coincidence that one of the trends in development is the implementation of microservice-oriented architectures. That would be the equivalent to the wiring, aqueduct, lighting and gas pipeline of the codified metropolises.
Unlike a place of retirement in the countryside where to spend the weekend and special dates, currently, isolated Software which house that adorns a pristine green plain, not only does not exist but offers a dubious utility.

I only know that nothing I know

Overcome the complexity that derives from the dependencies of the house or the system as a whole that makes its way into a specific environment, is properly entered into the matter, at the heart of the matter.
Creative works, be it a poem, a drawing, a plan or an algorithm, must deal with a quota of uncertainty, which is reflected just before the task begins. This uncertainty can be equated with writer’s block when he meets a blank page.
This immobilizing uncertainty becomes a sensitive issue especially when this product of creativity has to align with economic perspectives and fit into predictable planning. Usually, this uncertainty is derived and projected in the estimation of the completion date.

The assertiveness of the estimate and its catastrophic consequences in case of mistake are directly related to the degree of uncertainty.
This is evident, but often to reach this conclusion it is necessary to go through the pains and glories of the process and it is precisely then that uncertainty has dissipated.
In the construction and software development, eliminate the uncertainty a priori, at least in the technical aspects is the equivalent to start the development.
It is a paradox that has given rise to a number of methodologies and that each time an ambitious implementation or an innovative business model is charged. It is then a more grounded version of the Schrödinger cat analogy. Or the most sophisticated case of the chicken and the egg.

The Butterfly Effect

Finally, no matter how accurate the knowledge in construction or programming is, in order to execute the project, and even when taking precautions in resources, it is impossible to foresee every setback or inconvenience and the effect that these have on the final result. Even more so when the defined execution plan is composed of tightly linked tasks.
It is difficult to interpret with certainty the impact that a decision taken to solve an unexpected, for example, in the foundation of a building, will have on the building as a whole. A difference in the capacity of the planned aqueduct vs. the real one is as drastic for the final solution as the incompatibility between two central modules in a complex application.
There are cases where the differences between the ideal and the real are insignificant and the result is the expected one, just as there are cases where an error in the planning or interpretation of the situation plunges the project forever.

Expertise is key to mitigate contingencies and prevent them, but when catastrophe is determined to occur, it is inevitable — we must keep in mind that doctors sometimes make mistakes, bridges sometimes fall and the code, certainly sometimes it does not compile.

For the good fortune of our field, the pre and postoperative of the circuits is painless, the setting times are shorter and turning off and on the computer solves 90% of the problems.

After having made this reflection — and in part catharsis — of what it meant to build my house while building quality software, I discovered that context, uncertainty, and randomness are not characteristics alien to any human activity.

To elucidate this is aligned with the objective I set myself: to demonstrate that programming is a much more human than an extraterrestrial task.