- Plato: insights on mathematics, theory of forms, theory of chora.
- Aristotle's Categories.
- The history of emanationism from the Neoplatonists onward. Lovejoy's Great Chain of Being can be taken as a starting point.
- The historical evolution of the scholastic organon (particularly proto systems thinkers like Francisco Suárez).
- Robert Fludd and Athansius Kirchner passim, for whom the representation and logical retrieval of knowledge was elevated to an art form.
- Raymond Lully and Giordano Bruno, passim.
- The mathematical theology of Nicholas Cusanus.
- Leibniz's Dissertatio de arte combinatoria, writings on organon and Monadology.
- Diderot and D'Alembert.
- Kant's discussion of the very concept of System in the Architectonic from the Critique of Pure Reason.
- Kant's "philosophy as a system" passage from a preface to the Critique of Judgement.
- Fichte and Reinhold's post-Kantian systematic philosophies (in particular Fichte's Wissenschaftslehre).
- Hegel's Wissenschaft der Logik.
- Ernst Cassirer's theory of symbolic forms.
- Various other Neo-Kantians, but certainly Emil Lask's domain category concept, which resonates strongly with modern type theory.
- Martial Gueroult's Dianoématique project, which takes up the history of philosophy as a historical problem using comparative systems analysis.
- Jules Vuillemin's development of the notion of philosophical system in What are Philosophical Systems?
- Deleuze's Différence et répétition.
- Friedrich Kittler's work on the history of "code" in general, and programming languages in particular.
As he says, "The majority of these are of course not about software as such but rather the construction of epistemic systems. In so doing, these thinkers ran into the same issues you encounter in large-scale software projects. There is a kind of metacritical problem proper to both about arriving at the boundaries of symbolic cognition, hitting cognitive complexity thresholds."
TMurph is a crazy guy and I love the chutzpah behind such a list. Murph is ... he would hate that I lump in with them, but he's like oddly in the same vicinity of the "neorationalists" (philosophers who read Hegel and Deleuze or something and then get into theoretical computer science ... or the reverse really) like A A Cavia, Peter Wolfendale, Reza Negarestani, all very crazy people, again, but scarily erudite and intelligent
Also, I see that you have Brian Cantwell-Smith on your list, and like, I've read his introduction to his vaporware seven-volume set on computation, and it's still insightful as hell, I wish I could just shake the books on computation out of him.
The requirements analysis about finding out what people want
If I may elaborate,
Often entails finding out what they really want based on what they say and what they do
Taking exactly what they say they want doesn’t always works
In fact fails far more often than what school prepares you for
They don’t tell you enough because they themselves also don’t know what they don’t know.
You sometimes can provoke them to reveal about the don’t know what they don’t know but it’s a bit by luck.
Sometimes you cannot ask the right questions because this time it’s in your region of don’t know what you don’t know.
Even assuming you manage to sift out the actual requirements from the revealed preferences
Now you have to prioritise. Again you can ask but how accurate is another matter.
Even though you have divided into business analysis, requirements analysis etc, and the division makes logical sense, in reality these things are inter dependent.
To quote Steve McConnell to diagnose a complex problem completely, you must already have solved it halfway
Although formal training always teaches us to diagnose a problem completely first before starting to solve it!
My comments are to add color by an independent software vendor who has dealt with non technical stakeholders and illogical company policies at the client company over many years
Yup! You've covered concisely what will be a long upcoming section on requirements analysis. It's exceptionally meta-rational work because you have to turn stakeholder's nebulous ideas about what they want into a formal system.
> o turn stakeholder's nebulous ideas about what they want into a formal system.
It’s not even a once and done thing
Even when the formal system is live and working, there’s still software decay
Or in this case more accurately, pattern decay where the ontological models that were originally created to get the system live will eventually get more ill fitting
Nebulosity like entropy seems to increase over time when no attempts are made to improve existing ontological models or even outright remodel them
Oh just to be clear a lot of dilemmas faced during requirements analysis such as contradictory requirements, illogical requests, or super hard implementations are often solved via ontological remodeling
Yes indeed! This was the underlying intuition in Domain Driven Design, I think. Unfortunately the book on that was kind of a mess, and DDD got mostly turned into another brand of rationality theater. But its original idea was important and right, I think.
Software architecture is a team game, whether acknowledged or not, and the best architectures often emerge over time without any one specific architect. Organisational culture contributes more to good architecture than most acknowledge.
"Requirements" are a kind of bugbear of mine, because at the level of architecture often they are almost irrelevant. I mostly analyse business forces at play and consider desiderata I can forsee, rather than whatever random functionality is currently claimed to be crucial. After 25 years of doing this I am looking for an architecture which will survive the stress tests of development and production, which is often quite different. Conway's Law and corporate funding structures are more important than any particular feature, which will probably change radically anyway.
Determining the scope of the architecture exercise itself is itself architecture, and you can keep going more meta forever (which I guess is your point). I find at the early stage my role is really engineering the people in a sort of "project assurance" way - set the team up right and the correct architecture will emerge, and this varies from project to project and business to business.
These are all points my outline says I will discuss. I'd appreciate your feedback, as I post successive pieces of the story, on whether it reflects your experience, at a detailed level.
Yes, well, it's the introduction to a book chapter, so it's a head without a body. Splitting a book into newsletter posts isn't altogether natural. Sometimes it works well. "Penicillin" and "Sorcery" were both good as posts, I think. Sometimes not so well: "Making meta-rationality available" was somewhat too long, and this chunk is too short.
P.s. Marketing being involved in the architecture (vs requirements or visual design) is something I've never heard of, and so popped my "I trust this author" belief (locally, ignoring wider context)
Thanks! I have seen this happen in the wild, but it's clearly not best practice. I have revised accordingly. It now says:
> For that reason, architecting is also often done in close collaboration with people in the marketing department, who may sometimes force critical architectural decisions despite limited technical understanding.
Often still sounds too strong for my taste. If "often" changed to "sometimes even" then my objection would disappear. (No expectation/obligation to satisfy me, but I may represent a lot of Amooglesoft experiences)
Yes, I was going to say that this is partially dependent on the sort of company (and project, and other factors). Amooglesoft is atypical in various ways. I know little, but my impression is that they have very well-defined standard processes and siloed departments with well-defined interfaces and responsibilities and enough resources that people don't end up wearing multiple hats. It's very different from startups!
They can co-occur, but need not, and are conceptually distinct:
Meta-rationality = figuring out how best to use rationality. This might involve bringing to bear multiple disciplines, but most often doesn't.
Multi-disciplinary = applying concepts from multiple disciplines. This might not involve rationality, and (if it is done routinely) might not involve reasoning about how best to apply what material.
When, how much, which sort, how to apply it, what needs to go around it to make it work, what its purpose is, how that dovetails with other purposes, ...
For a turbo boost: conceptualize the entirety of reality as a hyper-realistic video game, populated by 7 billion+ semi-intelligent, semi-self-aware, semi-autonomous agents.
oddly reminds me of Thomas Murphy's magesterial "reading list" for software here: https://twitter.com/thomasmurphy__/status/1776995934066385244
I'll reproduce it below
- Plato: insights on mathematics, theory of forms, theory of chora.
- Aristotle's Categories.
- The history of emanationism from the Neoplatonists onward. Lovejoy's Great Chain of Being can be taken as a starting point.
- The historical evolution of the scholastic organon (particularly proto systems thinkers like Francisco Suárez).
- Robert Fludd and Athansius Kirchner passim, for whom the representation and logical retrieval of knowledge was elevated to an art form.
- Raymond Lully and Giordano Bruno, passim.
- The mathematical theology of Nicholas Cusanus.
- Leibniz's Dissertatio de arte combinatoria, writings on organon and Monadology.
- Diderot and D'Alembert.
- Kant's discussion of the very concept of System in the Architectonic from the Critique of Pure Reason.
- Kant's "philosophy as a system" passage from a preface to the Critique of Judgement.
- Fichte and Reinhold's post-Kantian systematic philosophies (in particular Fichte's Wissenschaftslehre).
- Hegel's Wissenschaft der Logik.
- Ernst Cassirer's theory of symbolic forms.
- Various other Neo-Kantians, but certainly Emil Lask's domain category concept, which resonates strongly with modern type theory.
- Martial Gueroult's Dianoématique project, which takes up the history of philosophy as a historical problem using comparative systems analysis.
- Jules Vuillemin's development of the notion of philosophical system in What are Philosophical Systems?
- Deleuze's Différence et répétition.
- Friedrich Kittler's work on the history of "code" in general, and programming languages in particular.
As he says, "The majority of these are of course not about software as such but rather the construction of epistemic systems. In so doing, these thinkers ran into the same issues you encounter in large-scale software projects. There is a kind of metacritical problem proper to both about arriving at the boundaries of symbolic cognition, hitting cognitive complexity thresholds."
That's great, thank you!
My somewhat similar list is here: https://meaningness.com/further-reading
(The section on "Computation, AI, and cognitive science” is most relevant)
TMurph is a crazy guy and I love the chutzpah behind such a list. Murph is ... he would hate that I lump in with them, but he's like oddly in the same vicinity of the "neorationalists" (philosophers who read Hegel and Deleuze or something and then get into theoretical computer science ... or the reverse really) like A A Cavia, Peter Wolfendale, Reza Negarestani, all very crazy people, again, but scarily erudite and intelligent
Also, I see that you have Brian Cantwell-Smith on your list, and like, I've read his introduction to his vaporware seven-volume set on computation, and it's still insightful as hell, I wish I could just shake the books on computation out of him.
> I wish I could just shake the books on computation out of him
So say we all!
(But I live in a glass house there; I’ve promised far more writing than I could ever get to.)
The requirements analysis about finding out what people want
If I may elaborate,
Often entails finding out what they really want based on what they say and what they do
Taking exactly what they say they want doesn’t always works
In fact fails far more often than what school prepares you for
They don’t tell you enough because they themselves also don’t know what they don’t know.
You sometimes can provoke them to reveal about the don’t know what they don’t know but it’s a bit by luck.
Sometimes you cannot ask the right questions because this time it’s in your region of don’t know what you don’t know.
Even assuming you manage to sift out the actual requirements from the revealed preferences
Now you have to prioritise. Again you can ask but how accurate is another matter.
Even though you have divided into business analysis, requirements analysis etc, and the division makes logical sense, in reality these things are inter dependent.
To quote Steve McConnell to diagnose a complex problem completely, you must already have solved it halfway
Although formal training always teaches us to diagnose a problem completely first before starting to solve it!
My comments are to add color by an independent software vendor who has dealt with non technical stakeholders and illogical company policies at the client company over many years
Yup! You've covered concisely what will be a long upcoming section on requirements analysis. It's exceptionally meta-rational work because you have to turn stakeholder's nebulous ideas about what they want into a formal system.
> o turn stakeholder's nebulous ideas about what they want into a formal system.
It’s not even a once and done thing
Even when the formal system is live and working, there’s still software decay
Or in this case more accurately, pattern decay where the ontological models that were originally created to get the system live will eventually get more ill fitting
Nebulosity like entropy seems to increase over time when no attempts are made to improve existing ontological models or even outright remodel them
Yes! This is also covered in the software chapter; it has a section on maintenance, and how the ontology may have to be updated over time.
Oh just to be clear a lot of dilemmas faced during requirements analysis such as contradictory requirements, illogical requests, or super hard implementations are often solved via ontological remodeling
Yes indeed! This was the underlying intuition in Domain Driven Design, I think. Unfortunately the book on that was kind of a mess, and DDD got mostly turned into another brand of rationality theater. But its original idea was important and right, I think.
Your description of the evolution of DDD literature mirror my own reading experience
At first exhilarating to read but the more I read, the more I feel nauseated 🤢
Insert link 🔗 for ontological remodeling https://metarationality.com/remodeling
A couple of random points off the top of my head.
Software architecture is a team game, whether acknowledged or not, and the best architectures often emerge over time without any one specific architect. Organisational culture contributes more to good architecture than most acknowledge.
"Requirements" are a kind of bugbear of mine, because at the level of architecture often they are almost irrelevant. I mostly analyse business forces at play and consider desiderata I can forsee, rather than whatever random functionality is currently claimed to be crucial. After 25 years of doing this I am looking for an architecture which will survive the stress tests of development and production, which is often quite different. Conway's Law and corporate funding structures are more important than any particular feature, which will probably change radically anyway.
Determining the scope of the architecture exercise itself is itself architecture, and you can keep going more meta forever (which I guess is your point). I find at the early stage my role is really engineering the people in a sort of "project assurance" way - set the team up right and the correct architecture will emerge, and this varies from project to project and business to business.
Thank you very much!
These are all points my outline says I will discuss. I'd appreciate your feedback, as I post successive pieces of the story, on whether it reflects your experience, at a detailed level.
I'd love to, this is totally in my wheelhouse :)
This ended abruptly and I was surprised.
Yes, well, it's the introduction to a book chapter, so it's a head without a body. Splitting a book into newsletter posts isn't altogether natural. Sometimes it works well. "Penicillin" and "Sorcery" were both good as posts, I think. Sometimes not so well: "Making meta-rationality available" was somewhat too long, and this chunk is too short.
Maybe a “to be continued” at the end to call this out? I’m reminded of the frequent multipart blog series on acoup.blog.
Good - as long as that's known/expected
P.s. Marketing being involved in the architecture (vs requirements or visual design) is something I've never heard of, and so popped my "I trust this author" belief (locally, ignoring wider context)
Thanks! I have seen this happen in the wild, but it's clearly not best practice. I have revised accordingly. It now says:
> For that reason, architecting is also often done in close collaboration with people in the marketing department, who may sometimes force critical architectural decisions despite limited technical understanding.
Often still sounds too strong for my taste. If "often" changed to "sometimes even" then my objection would disappear. (No expectation/obligation to satisfy me, but I may represent a lot of Amooglesoft experiences)
Yes, I was going to say that this is partially dependent on the sort of company (and project, and other factors). Amooglesoft is atypical in various ways. I know little, but my impression is that they have very well-defined standard processes and siloed departments with well-defined interfaces and responsibilities and enough resources that people don't end up wearing multiple hats. It's very different from startups!
Is it easy to discriminate between metarationality and multidisciplinary work?
How would you do that?
They can co-occur, but need not, and are conceptually distinct:
Meta-rationality = figuring out how best to use rationality. This might involve bringing to bear multiple disciplines, but most often doesn't.
Multi-disciplinary = applying concepts from multiple disciplines. This might not involve rationality, and (if it is done routinely) might not involve reasoning about how best to apply what material.
> Meta-rationality = figuring out how best to use rationality.
I like to think of it as when and how much of it to use.
That ok?
When, how much, which sort, how to apply it, what needs to go around it to make it work, what its purpose is, how that dovetails with other purposes, ...
Sounds almost like we need metarationality to also figure out meta rationality 😉
Yes, the "Ontological remodeling" chapter says exactly that:
> meta-rationality is required in order to understand meta-rationality.
For a turbo boost: conceptualize the entirety of reality as a hyper-realistic video game, populated by 7 billion+ semi-intelligent, semi-self-aware, semi-autonomous agents.
The rest of the story basically writes itself.