Seems to me there is a lot of resonance with the modern UX researcher and “product manager” (distinct from project manager), whose main job is to make sure you’re *solving the right problem.*
What’s fascinating to me is that a lot of the most thoughtful authors I’ve seen in this field (eg Indi Young) come from design backgrounds, where things are almost self evidently nebulous and there is no absolute right answer. Instead, all the work is in understanding the right *context and fit*.
They also have lots of exercises that are about getting your categories of and relationships between ideas right — ie a proto-ontology if you will. They call this “qualitative research”, and I think there are a lot of resonances with what you write about. At the end of the day, it’s about getting the abstract architecture of things right, appropriate for the moment and the purpose.
The concept of “friction” seems pretty relevant here. Clausewitz talked about it in relation to war, but it likely applies to nearly any human endeavor. Here’s a post about how it applies for software development:
> As throughout this chapter, the aim here is to help you better understand meta-rationality—not to better understand software development.
I'm interested in both meta-rationality and software development. My sense is that, even if the aim here *isn't* to better understand software development, it still has that effect on me. As mentioned previously, I think it would be valuable enough to my software development team members, that I want to share it with them--for the sake of better understanding our software development, even if they don't yet care about meta-rationality.
> even if the aim here *isn't* to better understand software development, it still has that effect on me
Oh, well, that's great!
There's a second half of this yet to come, on how to come to understand software purposes meta-rationally. That may be more relevant and useful for working developers than this, in fact. Soon, I hope!
I found this really helpful. And timely. I happen to be working on an intentionally nebulous software development project right now in my day job. It’s intentionally nebulous, to allow for discovery and experimentation.
I feel like your material would have been good reading for my team from the start. In fact, I think I’ll recommend to my team that we read and discuss this together.
That was a very interesting read. I need to follow up with the other parts of the book!
Regarding "getting the ontology right" and Domain-Driven Design in general, I started moving away from this approach recently (as a software designer). I don't think our software should be built on models of the domain. Instead I see software as tools with specific purposes aligned with the domain (i.e. solve breakdowns specific to this domain).
On the off chance you're not already aware of this work, Daniel Jackson's [The Essence of Software](https://essenceofsoftware.com/) goes in a similar direction by introducing concepts with specific purposes.
Regarding requirements engineering and why "requirements documents" do not make sense, I found Nam Suh's [The Principles of Design](https://www.amazon.com/Principles-Design-Oxford-Advanced-Manufacturing/dp/0195043456) very illuminating. He presents design as a zig-zag process between the WHAT (requirements) and the HOW (design parameters/decisions). The low-level requirements do not even exist until the high-level design decisions are made. Therefore, it is impossible to build a complete requirements document without designing the whole system.
Benoît, thank you very much for this comment (and for your new paying subscription!)
And, thanks especially for recommending Daniel Jackson's book. I'm surprised and embarrassed that I had not known about his work. You are right, it is extremely relevant. I've read his "Essence of the Essence" which was exciting, and have ordered a copy of the book on paper.
And also the Nam Suh book, which I've also ordered.
What I am about to expand on may be too much rationality.
Let me explain.
Getting the ontology right doesn't mean I have to get the cardinality 100% foolproof right.
Example, after speaking with all stakeholders, I decide that a relationship between entity Project and entity Task is the right ontology. However, I receive conflicting information from different people whether it should be one to many (i.e., 1 Project has many Tasks and each Task can ONLY belong to 1 Project) or many-to-many. This uncertainty over whether a relationship is 1 to many or many to many is uncertainty over cardinality.
I used to let this stop me from proceeding.
I also used to be very upset when the stakeholders gave me new information that they should have told me right from the start or they changed their mind, because the new info or change of mind resulted in a chnage of cardinality.
A change in cardinality isn't a big deal, but it does require rewriting code. And the amount of rewrite may be extensive depending how low or high in the hierarchy of things. E.g. if the change is something deeply fundamental, the resulting changes will be extensive.
Not caring about ontology is also not correct just because certain details about the ontology are more subject to changes or mistakes.
Basically, I have found not to let the perfect be the enemy of the good. Cardinality != Ontology and even then not all cardinalities are equally important. The more fundamental ones tend to lead to more extensive refactoring when they change *AFTER* code is written.
Trying to get the ontology right is still very important, but I think if there's more improvements in terms of making it less expensive to change things that cannot be decided early on, that would be even better.
> if there's more improvements in terms of making it less expensive to change things that cannot be decided early on, that would be even better.
Yes, definitely!
Many approaches to software design, language features, and framework features have flexibility of this general sort as a goal. Often that hasn't worked as well as hoped.
Long ago (late 80s) I sketched a framework that would make ontology explicit, with much of an app then flowing automatically from that. The product I led in the 1990s took ideas from that, which I think also helped make it a success.
I considered pulling out the framework and making it more general—it was somewhat specialized for the application—and making that a product, which would have much greater scope. I was too burned out by then to do it, although I still think it would have been a good idea.
MVC architectures in frameworks like Django do part of what is needed, I think. Just changing the cardinality declaration on the model can automatically change the UI and database schema and so on, updating in the right ways without your having to write any code.
There's still a lot more that is possible, I think!
I'm probably digressing from this article, but I cannot help share my own nerdy thoughts on this.
> flexibility of this general sort as a goal. Often that hasn't worked as well as hoped.
I am working towards this in my own small way.
Basically to help me with my daily work, i.e. writing web apps for enterprise software.
My current approach (and hypothesis) is:
- use a formal, text-based notation perhaps taking from systems engineering to describe problem specs and logical design,
- then use that as input into generative AI to output the code build and improve web app of a specific framework
I bought your book, "Better without AI", and followed some of the people you recommended in that book. So I'm aware of, and agree with you the objections you have with generative AI.
So this is experimental at this point.
> I considered pulling out the framework and making it more general—it was somewhat specialized for the application—and making that a product, which would have much greater scope.
It would be good even if you pull it out without making it more general at the moment.
> Django
Coincidentally, that's the framework I am focusing my experiment on.
So in short, purpose-wise, web forms for enterprise software. Tech stack is Django, or at most Django as backend + React as frontend.
Input would be some kind of higher order, formal notation as problem specs, and logical design.
Using my own example in the earlier comment, imagine changing the cardinality in the text-based formal notation from
one-to-many
```
// Objects
Project
Task
// Structural Relations
Project includes Task.
Task is part of Project.
```
to many-to-many
```
// Objects
Project
Task
// Structural Relations
Project is associated with Task.
Task is associated with Project.
```
Then, the generative AI that's trained on the specific target tech stack will generate the files and code accordingly.
> Just changing the cardinality declaration on the model can automatically change the UI and database schema and so on, updating in the right ways without your having to write any code.
Yes, that's what I am thinking as well in my own experiment. Precision and rigor still matter, but I am thinking if it's possible to do so at some higher-order level and leave it to machines (be it gen AI, or something else) to do it.
I don't rule out doing something deterministic like how Django does it with migrations for example. But, right now, I don't feel I'm smart enough to figure that out.
> There's still a lot more that is possible, I think!
Strong agree.
Just to circle back to your article, even if machines handling code changes turns out to be true and available in the future, your points about getting ontology right, and that software development is an activity teeming with nebulosity are not diminished.
In fact, I suspect your points will be more explicit and obvious.
If much of what's currently done by human junior developers can be done by machines (i.e. writing code to specs, writing unit tests, etc), then what defines the job of a software developer in that reality will be mostly figuring out the nebulosity and its implications.
I personally prefer that kind of reality frankly. Writing code is getting tedious for me now. I prefer solving problems and that usually means confronting inevitable nebulosity.
Code writing is one application for GPTs that seems to work well (for many people; opinions about this are strangely bimodal!). So your approach may work!
There's a long-standing objection to code generators (old-fashioned not-AI ones), which is that they may produce code that's great but if you need to modify it (for whatever reason) then you've decoupled the code from the spec that you initially gave to the generator. So either you need to never touch the generated code and do all maintenance by changing the spec and re-running the generator, or else you are stuck maintaining the code it output and never re-run it.
This problem seems like it would be at least as bad with code generated by an LLM.
> If much of what's currently done by human junior developers can be done by machines (i.e. writing code to specs, writing unit tests, etc), then what defines the job of a software developer in that reality will be mostly figuring out the nebulosity and its implications.
Yes, this seems a good insight!
> Writing code is getting tedious for me now. I prefer solving problems and that usually means confronting inevitable nebulosity.
This is a sign of maturation as a developer/engineer!
I was never sure if RUP was an actual thing that companies used and believed in 30+ years ago, or if it was a Boogeyman exaggerated by the Agile stories... 🤣
I can at least attest that companies paid money for people like me to board airplanes and fly out of state to get certified in using RUP. Whether the company culture back home would tolerate *using* it on real work--that's another story.
Love it. I know you weren't impressed with the Domain Driven Design book but contemporary DDD practices are exactly for this kind of nebulosity and getting the ontology right.
Wish I had this to read when I started my career "gathering requirements" would have saved a few projects.
This feels like a long argument for agile (or just the build, deploy, learn, iterate cycle) - is it more inherently meta-rational then? Would be interesting to hear that explored!
Glad you like it! Yes, there’s a second half coming “soon,” which will explain how one can engage with purposes meta-rationally when doing software development.
Fascinating stuff.
Seems to me there is a lot of resonance with the modern UX researcher and “product manager” (distinct from project manager), whose main job is to make sure you’re *solving the right problem.*
What’s fascinating to me is that a lot of the most thoughtful authors I’ve seen in this field (eg Indi Young) come from design backgrounds, where things are almost self evidently nebulous and there is no absolute right answer. Instead, all the work is in understanding the right *context and fit*.
They also have lots of exercises that are about getting your categories of and relationships between ideas right — ie a proto-ontology if you will. They call this “qualitative research”, and I think there are a lot of resonances with what you write about. At the end of the day, it’s about getting the abstract architecture of things right, appropriate for the moment and the purpose.
Thanks! Yes, highly relevant. These points are explicit in my next couple of posts on this subject.
The concept of “friction” seems pretty relevant here. Clausewitz talked about it in relation to war, but it likely applies to nearly any human endeavor. Here’s a post about how it applies for software development:
https://www.hillelwayne.com/post/software-friction/
> As throughout this chapter, the aim here is to help you better understand meta-rationality—not to better understand software development.
I'm interested in both meta-rationality and software development. My sense is that, even if the aim here *isn't* to better understand software development, it still has that effect on me. As mentioned previously, I think it would be valuable enough to my software development team members, that I want to share it with them--for the sake of better understanding our software development, even if they don't yet care about meta-rationality.
> even if the aim here *isn't* to better understand software development, it still has that effect on me
Oh, well, that's great!
There's a second half of this yet to come, on how to come to understand software purposes meta-rationally. That may be more relevant and useful for working developers than this, in fact. Soon, I hope!
I found this really helpful. And timely. I happen to be working on an intentionally nebulous software development project right now in my day job. It’s intentionally nebulous, to allow for discovery and experimentation.
I feel like your material would have been good reading for my team from the start. In fact, I think I’ll recommend to my team that we read and discuss this together.
That was a very interesting read. I need to follow up with the other parts of the book!
Regarding "getting the ontology right" and Domain-Driven Design in general, I started moving away from this approach recently (as a software designer). I don't think our software should be built on models of the domain. Instead I see software as tools with specific purposes aligned with the domain (i.e. solve breakdowns specific to this domain).
On the off chance you're not already aware of this work, Daniel Jackson's [The Essence of Software](https://essenceofsoftware.com/) goes in a similar direction by introducing concepts with specific purposes.
Regarding requirements engineering and why "requirements documents" do not make sense, I found Nam Suh's [The Principles of Design](https://www.amazon.com/Principles-Design-Oxford-Advanced-Manufacturing/dp/0195043456) very illuminating. He presents design as a zig-zag process between the WHAT (requirements) and the HOW (design parameters/decisions). The low-level requirements do not even exist until the high-level design decisions are made. Therefore, it is impossible to build a complete requirements document without designing the whole system.
Benoît, thank you very much for this comment (and for your new paying subscription!)
And, thanks especially for recommending Daniel Jackson's book. I'm surprised and embarrassed that I had not known about his work. You are right, it is extremely relevant. I've read his "Essence of the Essence" which was exciting, and have ordered a copy of the book on paper.
And also the Nam Suh book, which I've also ordered.
> I succeeded by getting the ontology right.
What I am about to expand on may be too much rationality.
Let me explain.
Getting the ontology right doesn't mean I have to get the cardinality 100% foolproof right.
Example, after speaking with all stakeholders, I decide that a relationship between entity Project and entity Task is the right ontology. However, I receive conflicting information from different people whether it should be one to many (i.e., 1 Project has many Tasks and each Task can ONLY belong to 1 Project) or many-to-many. This uncertainty over whether a relationship is 1 to many or many to many is uncertainty over cardinality.
I used to let this stop me from proceeding.
I also used to be very upset when the stakeholders gave me new information that they should have told me right from the start or they changed their mind, because the new info or change of mind resulted in a chnage of cardinality.
A change in cardinality isn't a big deal, but it does require rewriting code. And the amount of rewrite may be extensive depending how low or high in the hierarchy of things. E.g. if the change is something deeply fundamental, the resulting changes will be extensive.
Not caring about ontology is also not correct just because certain details about the ontology are more subject to changes or mistakes.
Basically, I have found not to let the perfect be the enemy of the good. Cardinality != Ontology and even then not all cardinalities are equally important. The more fundamental ones tend to lead to more extensive refactoring when they change *AFTER* code is written.
Trying to get the ontology right is still very important, but I think if there's more improvements in terms of making it less expensive to change things that cannot be decided early on, that would be even better.
> if there's more improvements in terms of making it less expensive to change things that cannot be decided early on, that would be even better.
Yes, definitely!
Many approaches to software design, language features, and framework features have flexibility of this general sort as a goal. Often that hasn't worked as well as hoped.
Long ago (late 80s) I sketched a framework that would make ontology explicit, with much of an app then flowing automatically from that. The product I led in the 1990s took ideas from that, which I think also helped make it a success.
I considered pulling out the framework and making it more general—it was somewhat specialized for the application—and making that a product, which would have much greater scope. I was too burned out by then to do it, although I still think it would have been a good idea.
MVC architectures in frameworks like Django do part of what is needed, I think. Just changing the cardinality declaration on the model can automatically change the UI and database schema and so on, updating in the right ways without your having to write any code.
There's still a lot more that is possible, I think!
I'm probably digressing from this article, but I cannot help share my own nerdy thoughts on this.
> flexibility of this general sort as a goal. Often that hasn't worked as well as hoped.
I am working towards this in my own small way.
Basically to help me with my daily work, i.e. writing web apps for enterprise software.
My current approach (and hypothesis) is:
- use a formal, text-based notation perhaps taking from systems engineering to describe problem specs and logical design,
- then use that as input into generative AI to output the code build and improve web app of a specific framework
I bought your book, "Better without AI", and followed some of the people you recommended in that book. So I'm aware of, and agree with you the objections you have with generative AI.
So this is experimental at this point.
> I considered pulling out the framework and making it more general—it was somewhat specialized for the application—and making that a product, which would have much greater scope.
It would be good even if you pull it out without making it more general at the moment.
> Django
Coincidentally, that's the framework I am focusing my experiment on.
So in short, purpose-wise, web forms for enterprise software. Tech stack is Django, or at most Django as backend + React as frontend.
Input would be some kind of higher order, formal notation as problem specs, and logical design.
Using my own example in the earlier comment, imagine changing the cardinality in the text-based formal notation from
one-to-many
```
// Objects
Project
Task
// Structural Relations
Project includes Task.
Task is part of Project.
```
to many-to-many
```
// Objects
Project
Task
// Structural Relations
Project is associated with Task.
Task is associated with Project.
```
Then, the generative AI that's trained on the specific target tech stack will generate the files and code accordingly.
> Just changing the cardinality declaration on the model can automatically change the UI and database schema and so on, updating in the right ways without your having to write any code.
Yes, that's what I am thinking as well in my own experiment. Precision and rigor still matter, but I am thinking if it's possible to do so at some higher-order level and leave it to machines (be it gen AI, or something else) to do it.
I don't rule out doing something deterministic like how Django does it with migrations for example. But, right now, I don't feel I'm smart enough to figure that out.
> There's still a lot more that is possible, I think!
Strong agree.
Just to circle back to your article, even if machines handling code changes turns out to be true and available in the future, your points about getting ontology right, and that software development is an activity teeming with nebulosity are not diminished.
In fact, I suspect your points will be more explicit and obvious.
If much of what's currently done by human junior developers can be done by machines (i.e. writing code to specs, writing unit tests, etc), then what defines the job of a software developer in that reality will be mostly figuring out the nebulosity and its implications.
I personally prefer that kind of reality frankly. Writing code is getting tedious for me now. I prefer solving problems and that usually means confronting inevitable nebulosity.
Code writing is one application for GPTs that seems to work well (for many people; opinions about this are strangely bimodal!). So your approach may work!
There's a long-standing objection to code generators (old-fashioned not-AI ones), which is that they may produce code that's great but if you need to modify it (for whatever reason) then you've decoupled the code from the spec that you initially gave to the generator. So either you need to never touch the generated code and do all maintenance by changing the spec and re-running the generator, or else you are stuck maintaining the code it output and never re-run it.
This problem seems like it would be at least as bad with code generated by an LLM.
> If much of what's currently done by human junior developers can be done by machines (i.e. writing code to specs, writing unit tests, etc), then what defines the job of a software developer in that reality will be mostly figuring out the nebulosity and its implications.
Yes, this seems a good insight!
> Writing code is getting tedious for me now. I prefer solving problems and that usually means confronting inevitable nebulosity.
This is a sign of maturation as a developer/engineer!
I was never sure if RUP was an actual thing that companies used and believed in 30+ years ago, or if it was a Boogeyman exaggerated by the Agile stories... 🤣
I had a friend who worked at Rational ~30 years ago, so I can testify that it existed then!
It was bought by IBM ~20 years ago, and you can still buy Rationality from them: https://public.dhe.ibm.com/software/rational/web/datasheets/RUP_DS.pdf
It doesn't come cheap, though!
I can at least attest that companies paid money for people like me to board airplanes and fly out of state to get certified in using RUP. Whether the company culture back home would tolerate *using* it on real work--that's another story.
Anyway, I was a certified believer in my 20s.
Really liked this.
Typo: "It might buggy software"
Glad you liked it, and thanks for pointing out the typo! I've fixed it now.
Love it. I know you weren't impressed with the Domain Driven Design book but contemporary DDD practices are exactly for this kind of nebulosity and getting the ontology right.
Yes, I'll be covering DDD in the next section (coming after the second half of this section on requirements/purposes)!
Can you recommend anything to better and more current to read about it?
Its hard because ironically subtleties of DDD are very tacit.
"Learning Domain Driven Design" by Vlad Khononov has way clearer language.
If you want get an overview of what contemporary practices exist (with the danger of intepreting them as a rationalist approach): https://github.com/ddd-crew/ddd-starter-modelling-process
An experience report from a couple of weeks ago about how Evan himself teaches DDD:
https://read.ceilfors.com/p/unspoken-secrets-of-ddd-lessons-from-eric-evans
https://read.ceilfors.com/p/concrete-examples-to-deepen-understanding
Thank you, this is very helpful! I will read all of them before writing the ontology/DDD section.
Wish I had this to read when I started my career "gathering requirements" would have saved a few projects.
This feels like a long argument for agile (or just the build, deploy, learn, iterate cycle) - is it more inherently meta-rational then? Would be interesting to hear that explored!
Glad you like it! Yes, there’s a second half coming “soon,” which will explain how one can engage with purposes meta-rationally when doing software development.