Today Hey.com launched a new feature, now I have a personal blog space directly from my e-mail account. Let's give it a try. These are my thoughts on a subject that I have been thinking about for some years: The Role of Software
Businesses have real challenging requirements and most of the difficulty is not tied up with the actual implementation of those requirements - they are quite straightforward, however accounting for changes is the tricky one and often very misunderstood.
We have always lived in an ever changing environment, but the rate of change is really high from either the business or technology perspectives. I had the pleasure to work with smart business people and often felt their despair when they explained a new feature or a new pivoting in the product and the tech department went mad by thinking about how would they do that?
It seems to me that when a smart team want to account for flexibility and to be able to change at will the last resort is parameterization which is basically deferring some decisions to runtime.(assuming you have good abstractions in your code in-place)
Of course I am oversimplifying, everybody knows that a well defined context map created in partnership with great domain experts who knows all the answers, with microservices running on service meshes exchanging well-defined messages can quickly perform any task at hand.
Often all of this works for small scale flexibility, but if you listen carefully to how some business people talk about their products and visions the level of change can vary drastically.
In Clojure community we have a known term called PLOP or "Place-Oriented programming" which is related to finding the correct place to add/remove/read/write data/code that must live from now on in the way you wrote/designed. The problem for me is that the correct place can only be known at a time, or better yet, at the time of implementation which means almost right now if you consider a time frame of 5 to 10 years. Another aspect of PLOP is a careful coordination between all the code to make it work.
Very small trivia example, today we know that a piece of data from real world is represented by these 3 fields. We promptly write a function that accepts this data and return a very meaningful answer: 42.
Businesses have real challenging requirements and most of the difficulty is not tied up with the actual implementation of those requirements - they are quite straightforward, however accounting for changes is the tricky one and often very misunderstood.
We have always lived in an ever changing environment, but the rate of change is really high from either the business or technology perspectives. I had the pleasure to work with smart business people and often felt their despair when they explained a new feature or a new pivoting in the product and the tech department went mad by thinking about how would they do that?
It seems to me that when a smart team want to account for flexibility and to be able to change at will the last resort is parameterization which is basically deferring some decisions to runtime.
Of course I am oversimplifying, everybody knows that a well defined context map created in partnership with great domain experts who knows all the answers, with microservices running on service meshes exchanging well-defined messages can quickly perform any task at hand.
Often all of this works for small scale flexibility, but if you listen carefully to how some business people talk about their products and visions the level of change can vary drastically.
In Clojure community we have a known term called PLOP or "Place-Oriented programming" which is related to finding the correct place to add/remove/read/write data/code that must live from now on in the way you wrote/designed. The problem for me is that the correct place can only be known at a time, or better yet, at the time of implementation which means almost right now if you consider a time frame of 5 to 10 years. Another aspect of PLOP is a careful coordination between all the code to make it work.
Very small trivia example, today we know that a piece of data from real world is represented by these 3 fields. We promptly write a function that accepts this data and return a very meaningful answer: 42.
(def real-world-data
{:name "Wand",
:yob "1991",
:status "puzzled"})
(my-important-business-logic real-world-data)
;;=> 42Tomorrow, the world will change and we will receive a new piece of data:
(def real-world-tomorrow-data
{:name "Wand",
:city "SP",
:idea "none",
:yob "1991",
:weird/value-we-never-saw "Look for good questions, answers are generally boring"
:status "puzzled"})Why this should break your code? It's the same thing in disguise.
But if your code strictly depends on what you type/know right now how can you be prepared to deal with the future without eventually throwing everything away? We can have a good feeling about how space is important for developers when we look at our tooling: IDEs, testing frameworks, snapshots in general, etc. We are used to look at the code in static snapshots, so we can make sense of it. We can go back in time, but that's all that is. Even understanding how the past contributed to the present is very difficult.
Based on Bret Victor's excellent talk Inventing on Principle, I like to think that I am close to find a good principle to dedicate some work into it. Time. Software on time. Aristotle created a concept called "aporÃa" which means difficulty, logical impasse, contradiction, and thinking about time quickly converge to this concept.
But not all is lost, Computer Science have many attempts to investigate the nature of our Place-Oriented Programming models and maybe this was inherited from very early on. The following paper from John Backus is very interesting read Can programming be liberated from the von Neumann style? a functional style and its algebra of programs. I'm still researching all these concepts and looking at other fields has been helpful. There is a wonderful book called How Buildings Learn: What happens after they are built which describes the same kind of problem, but for physical buildings.
There are many places to look and definitely some communities are more aligned than others, however the daily basis of our work and the tendency for bikeshedding can be very distracting. I would like to finish this post with a quote from How Buildings Learn:
Buildings have often been studies whole in space, but never before have they been studied whole in time.... the book proposes that buildings adapt best when constantly refined and reshaped by their occupants, and that architects can mature from being artists of space to becoming artists of time.
If you find frustrating to read all this post and don't see any single conclusion or actionable item, consider the text some form of call for action. You can always find me on my email wand@hey.com.