A look into the disruption driven by AI on software, with a long detour on Serverless, and a spicy touch of disagreement with Simon Wardley
Cryptocurrencies considered beneficial
In my previous post I explained why I believe cryptocurrencies may be considered harmful. Now, may cryptocurrencies be seen as beneficial somehow too? This is what this second post is about!
Cryptocurrencies considered harmful
Is the web3 promise of a society free of centralised institutions and big companies nigh? Are cryptocurrencies the right way there? Or do they carry even more evil with them? In a word, may we consider cryptocurrencies harmful?
The sense of the Past
In the first post of this series we wondered how an application based only on Events would look like. To construct a proof of concept for this idea, in this second post we investigate data persistence under a different view.
Event Daydreaming
Imagine a software application based only on Events. How would it be? And, what benefits that kind of architecture would bring?
Let’s not Cancel the Algorithm
With more and more people calling for banning algorithms from our lives, the truth is that algorithms do work. Is there an escape from this computational horror?
Fiction in software – part two
If narratives are just fiction, why do they matter? In this second part of the series, we explore our true nature as storytellers, and what happens when software application projects fail.
Fiction in software – part one
Fiction narratives lay in the core of software design. This first part in a series of two explores two examples: a narrative based on transactions, and a narrative based on Events.
Into the timestream
Let's continue our exploration of the Domain and its representations in the code, we make a look into the timestream!
The role of Domain Coach
How can we make the most of the Domain-based methodologies to create software? The Domain Coach may a good answer to this question. But, wait, what is a Domain Coach?
But, what is the Domain?
If the Domain was a Universe, the vast collection of models that we create in our code to represent it would be a Multiverse.
The future of software: the dream is over
Is software becoming so regulated, so expensive, and so important in our software-driven lives that the developer job is becoming not exciting anymore?
Dumb by the pattern
Are we developers software crafters, or mere pattern implementors?
Absolutely not a gift
Is there a gift economy? Or, there are more unaverted connections among us that explain how free sharing yields economical value?
Architecture tests
Architecture tests check that software keeps in full compliance of architecture decisions (or ADRs) after code changes were committed.
We have nothing forbidden to learn
Here I propose Continuous Change, a new methodology for creating software with only one foundational pillar: never stop challenging our code, never stop changing our software..
Monoliths are averse to change
I consider the aversion to change that monoliths exhibit as their defining feature. And the benefits of embracing change in organizations based on software are explored.