Karl Popper described science - I think convincingly - like this:
A theory cannot be proven true, only disproven by experiment.
Therefore, falsifiability is a critical feature of scientific theories. A theory needs to make predictions that could be proven false by observation.
It follows that when testing a theory, focus on how you might prove it wrong.
If you fail to disprove it, then you might tentatively accept the theory as the best explanation we have so far!
And that acceptance will lead to more theories which we can then try to falsify.
He described this process as one of alternating cycles of “conjecture” (coming up with a theory) and “refutation” (attempting to falsify or criticise the theory).
I was introduced to this idea by David Deutsch’s book The Beginning of Infinity, where he uses the phrase “conjecture and criticism”, which alliterates nicely.
I prefer the more colloquial “guess and check”.
I think this cycle also describes common practises involved in developing software.
Writing the source code of, say, a sorting function is a conjecture: “I guess this source code correctly implements the quicksort algorithm”.
Writing a test case is one way of “refuting”, “criticising”, or checking your conjectural source code. We usually supply “happy path” examples which, while not constituting “proof”, do provide some evidence. If these attempts to falsify your conjecture fail, you might be happy to proceed, depending on how complicated the original code is.
Property-based testing is a way to automatically generate a lot of criticism, provided you have a way of judging the output. The properties themselves are further conjectures, for example of the form “I guess this source code checks that all elements of a list are smaller than their successor”. We depend on these properties being easier to state in code than the function they’re checking!
Proofs and model checking approach the problem from a different direction. Additional conjectures such as “this proof correctly models the problem of sorting” or “this model accurately reflects the system I am building”, combined with “this source code corresponds accurately to this proof statement or model component” can be subject to their own criticism. A proof checker, itself correctly implemented, supplies criticism of a proof text.
I’ve described writing both the original code, and the tests or properties or proofs, as conjectural. In my view these approaches to the same underlying “explanation”, from different angles, buttress each other - acting as potential refutations of each other’s conjecture.
Different modes of expression - source code, examples, properties, proofs - give our minds different affordances to express and explain ourselves. Where these different expressions intersect and either agree or disagree, we get to understand the mistakes we made in each expression.
It’s by challenging ourselves that we can be more confident that our theories, our guesses, about what our code is doing. As Popper translated Xenophanes:
As for certain truth, no one has known it … and even if by chance he were to utter the perfect truth, he would himself not know it; for all is but a woven web of guesses.
A Pattern Language (APL) is one of my favourite books.
When I first read it, I was surpriseds that it explained a bunch of things that I already found beautiful in buildings.
It’s also an early example of a hypermedia text which can be read non-linearly, like an archipelago of islands connected by bridges.
But one of its most grandiose pretensions, which I really enjoy, is that it takes seriously that architecture is part of society.
How seriously does it take this?
Here’s the first pattern in the book:
1. Independent Regions**
Metropolitan regions will not come to balance until each one is small and autonomous enough to be an independent sphere of culture. … Therefore: wherever possible, work toward the evolution of independent regions in the worId; each with a population between 2 and 10 million; each with its own natural and geographic boundaries; each with its own economy; each one autonomous and self-governing; each with a seat in a world government, without the intervening power of larger states or countries.
(The ** after the pattern name indicates the authors believe they have discovered a truly fundamental and necessary pattern.)
Want good buildings? Start by reorganising the geopolitical framework of the entire world. Maybe it’s no wonder the pattern language proved impractical.
The book proceeds downards in scale from there, through the layout of settlements within a region and their relationship to the countryside (3. City Country Fingers), the arrangement of neighbourhoods (8. Mosaic of Subcultures) and their connections (16. Web of Public Transportation), streets (49. Looped Local Roads), blocks (38. Row Houses), buildings (107. Wings of Light), rooms (142. Sequence of Sitting Spaces), all the way on down to the details of the windowsills. Pattern 240. Half-Inch Trim** (another double star), lays out the problem thus:
Totalitarian, machine buildings do not require trim because they are precise enough to do without. But they buy their precision at a dreadful price: by killing the possibility of freedom in the building plan.
Along the way, the book detours into aged care (40. Old People Everywhere), industrial relations (80. Self-Governing Workshops And Offices), public service (149. Reception Welcomes You), religion (66. Holy Ground) and nightlife (63. Dancing In The Street). It addresses construction (218. Wall Membranes) and wildlife (74. Animals).
It’s an impossibly broad scope, and I love it.
It acknowledges and confronts the interconnectedness of building - how even the smallest project will be influenced by these larger scales.
I wish APL’s imitators had tried to mimic even a fraction of this ambition.
To software:
The core idea of the pattern language which can be used to generate infinitely many works that share common structural qualities was adopted in the software world, to the extent that the most famous of the book’s authors, Christopher Alexander, was invited to speak at the OOPSLA conference in 1996 to a crowd of object-oriented programmers.
The idea of design patterns has inspired many programming works.
The most famous is probably the “gang of four” patterns book from 1994.
Another is Kent Beck’s “Implementation Patterns” from 2007.
Yet another (rarely discussed as an entry in the “pattern” genre), is the original Domain-Driven Design “blue book” by Eric Evans in 2004.
The book explicitly models its chapters after APL’s pattern structure, with a problem statement and solution.
But no work in software that I’m aware of tries to imitate the sheer dynamic range of APL.
The GOF book and Implementation Patterns are concerned with the smallest details of code (functions and classes) within a single process.
Microsoft or AWS’s “cloud design patterns” resources address the integration of multiple processes.
The DDD book looks at the question of desinging an entire software system. It crosses over into the “rest of the business” with ideas like the universal language, and its discussions of how to work with experts to understand a domain. But it also focuses quite deep down into actual code and syntax.
I’m not aware of a software book about organisational structure (e.g. Team Topologies) that is pattern-oriented.
No single pattern language could encompass the massive variety of software development - and despite APL’s grandeur, the authors don’t pretend it is the only pattern language that should exist for architecture.
But fundamentally I believe that the economic environment in which code is written dramatically affects the right low-level syntax that should evolve, so explicitly weaving thogether those highest and lowest levels would be fascinating.
Just one example: Alex Russell’s struggle against careless organisational slop in his Reckoning series really reminds me of Alexander et al’s fight with bureaucracy in The Oregon Experiment.
A pattern language for web development should address how to generate healthy relationships between the users, the development team, management, and other stakeholders, as well as how not to get Alex to write an entire case study about you.
In software, we get plenty of advice about how to make beautiful windowsills.
But we don’t realise how connected that is to the whole world order.
We talk about “abstractions” a lot in software development.
Abstraction can sometimes mean “a way to hide details that aren’t relevant to helping me achieve my goals”.
This is what we mean by “abstracting away” an implementation.
Sometimes, per Dijkstra, an abstraction might mean “not to be vague, but to create a new semantic level in which one can be absolutely precise”.
This tantalising idea feels like doing real intellectual work, the kind involved in discovering things like twos-complement integers or Prolog.
Sometimes (and this is what I want to write about), abstraction means “an entity which isn’t tangible, but is nevertheless real and significant”.
This is the “abstract noun” sense of the word.
This is the sense David Deutsch used in a chapter of The Beginning of Infinity titled “The Reality of Abstractions”.
He writes:
In regard to what is or is not real, this leads to the requirement that, if an entity is referred to by our best explanation in the relevant field, we must regard it as really existing.
He intends here to counter the reductionist idea in science that the most low-level or fundamental phenomena (like quantum mechanics) are the only things that are “real” or significant.
He gives this example, comparing “high-level” explanations with a hypothetical reductionist explanation:
Consider one particular copper atom at the tip of the nose of the statue of Sir Winston Churchill that stands in Parliament Square in London. Let me try to explain why that copper atom is there. It is because Churchill served as prime minister in the House of Commons nearby; and because his ideas and leadership contributed to the Allied victory in the Second World War; and because it is customary to honour such people by putting up statues of them; and because bronze, a traditional material for such statues, contains copper, and so on. Thus we explain a low-level physical observation - the presence of a copper atom at a particular location - through extremely high-level theories about emergent phenomena such as ideas, leadership, war and tradition.
Presumably a reductive ‘theory of everything’ would in principle make a low-level prediction of the probability that such a statue will exist, given the condition of (say) the solar system at some earlier date. … But such descriptions and predictions would explain nothing. They would merely describe the trajectory that each copper atom followed from the copper mine, through the smelter and the sculptor’s studio and so on … In fact such a prediction would have to refer to atoms all over the planet, engaged in the complex motion we call the Second World War, among other things.
This might seem obvious? The reductionist approach to science isn’t one we encounter in our daily lives, and addressing it isn’t usually necessary.
But I keep thinking about the idea that “if an entity is referred to by our best explanation … we must regard it as really existing” and how it crops up when doing software design.
I don’t yet know exactly how to turn this vague idea into something graspable. It just keeps feeling relevant.
This often comes up when trying to understand a new part of our business domain at work.
A concept that initially sounded like a simple relationship between two entities turns out to have a whole life of its own, full of complexity we previously elided.
Two concepts that initially seemed similar turn out to have different underlying needs, and diverge.
Database tables need careful thought to walk the line between “what do we know for sure?” and “what do we need to leave room for in the future?”
It also influences how I think about so-called “natural keys” in databases.
Natiral keys encourage thinking of a database row as transparent, nothing more than a reflection of some external, more fundamental reality.
On the contrary, oir “best explanation” of software behaviour often included the existence (or absence) of a specific row in a database.
It deserves its own identity.
In some education about data-oriented design, a “data reductionism” can arise which sounds a lot like this:
Data is all we have. Data is what we need to transform in order to create a user experience. Data is what we load when we open a document. Data is the graphics on the screen, the pulses from the buttons on your gamepad, the cause of your speakers producing waves in the air … Abstraction heavy paradigms try to pretend the computer and its data do not exist at every turn, abstracting away the idea that there are bytes, or CPU pipelines, or other hardware features, and instead bringing the model of the problem into the program.
It’s necessary to climb down off the top of the object-oriented ladder of abstraction sometimes.
But I think the right outcome is to realise that what is needed is not no abstractions, but different ones.
Abstract notions like “quaternion” still exist, even if you are handling a packed table of floats instead of a tangled graph of pointers.
As the problem of performance moved from minimising CPU cycles to maximising cache utilisation, the correct abstraction to address a concrete need may have changed.
But retreating to “it’s all bytes!” is as insufficient as saying “what a peculiar arrangement of copper atoms you have there”.
*I use Fastmail’s “snooze” instead of making a task somewhere else.
Fernando wonders why so few apps have inboxes that work with this algorithm:
This is the utility of inbox zero: it has no false negatives! If the inbox is empty, I know that all of my correspondence has been handled. If the inbox is non-empty, I know there is work to do.
I have been finding that an RSS reader is a great way to treat the web like an inbox.
Prompted by the Australian government tinkering with zany news media regulations a few years ago, I wrote about how RSS is a great way to consume the news (or, it would be, if news organisations wanted it to be):
Instead of being at the mercy of “the algorithm” implemented by various social media sites, I get to act out the “inbox algorithm”:
Pick the site I’m in the mood for
Skim the headlines
If an article is short and I want to read it immediately, read it
If I can’t read it immediately, send it to Raindrop to read later
Mark all articles in the site as read
Newsblur, which I have been using for many years, makes this more or less the default experience.
Though, I understand some RSS apps are more focused on a “feed”-like experience.
Hearing this is what made me realise that Newsblur was letting me treat the web like an inbox, not like a feed.
One commenter on Hacker News describes the reason for feeds as:
the whole problem with chronological feeds, including RSS - chronological feeds incentivises spam-posting, posters compete on quantity to get attention. That’s one of the main reasons fb and other sites implemented algorithmic feeds in the first place
That is a problem with chronological feeds that mix content from all sources into a single view.
But any good RSS app will break down posts by source.
When confronted with a high-volume source with hundreds of unread posts, I used to skim a few posts at a time then just mark the whole site as read.
No point lying to myself about my ability to get through it all.
Other people use rating and intelligence systems to curate their own RSS feeds.
Newsblur has this kind of functionality built in, but I haven’t tried to use it.
These days, I just don’t tend to subscribe to high-volume sites via RSS (aggregators, whether user-contributed or traditional news organisations).