Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well.
I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard, a workflow, or an integration.
And once a B2B customer gets a taste of vibe coding... then it's just a matter of time before they start to think about replacing the entire SaaS completely. I have seen this play over and over again so many times in the last few months, it's honestly shocking.
I am working to find solutions to the SaaSpocalypse but don't want to derail from the main topic, there's more info in my profile if this has been something you're thinking about!
This is quite insightful. Often in my projects, some central nouns come up over and over again in discussions about architecture, until they become embedded in the actual software and the interface.
Since I started using AI tools to assist, I've found a lot of both utility and frustration revolves around my use of these nouns in prompts (in the context of, e.g. "during the 'quickpay' confirmation phase..."). When the bot settles into understanding these nouns, it seems to get a better handle on the architecture as a whole. When it suddenly forgets them and has to go figure out what they mean by scanning the code base, I know it's about to do something staggeringly redundant and stupid.
Makes me wonder if a similar level of analysis was done in reverse to conceive these, hopefully not word yahtzee. At least they don't end with "ly" - the horror.
Identifying the right taxonomy is not only an exercise in naming things, but also building the appropriate data structures and systems in your programs. I think this exercise is incomplete in the absence of studying how these nouns interact with one another.
I don't think that a loose-hanging 'payment intent' evokes a particular emotion, without its constituents' (credit cards, direct debits, cryptocurrencies) relationship to other nouns (customers, invoices, taxes, countries).
Kinda feels like identifying the key user stories with a bit too much naval gazing at the implementation.
That said, the implementations start to gain their own weight as user expectation grows to meet the implementation. I suppose the noun thinking is not entirely frivolous for an established app with expected core workflows and design language.
This makes me think of domain models in domain-driven design. Very useful to think about what these models are and how it makes sense to set them up & relate them in your area of work.
Something frustrating is when a company is being _clever_ with their nouns. Sometimes it's relatively innocuous, but spending time remembering what unique name I should be searching for instead of something obvious is not my idea of a good time.
Prompt engineering, hallucinations, quota, context limit, auto compaction.
Sometimes the nucleus aren't just nouns are barely mentioned.
So.. Jargon? Are we talking about Jargon?
Jargon is basically just a DSL on top of English :)
"Knowing names is my job. My art. To weave the magic of a thing, you see, one must find its true name out. In my lands we keep our true names hidden all our lives long, from all but those whom we trust utterly; for there is great power, and great peril, in a nam- what's that? Yes, I did move the Issue into the Backlog before starting the Sprint. No, it was seven Story Points. Break it down into two Subtasks? Yeah, can do. Then I'll mark it as Ready." -- Ursula K. Le Guin (mostly)
Really cool framing, never saw this broken down this way
[dead]
Interesting that "verb" does not appear in the posted article. I immediately thought of Yegge's kingdom of nouns blog post, which is 20 years old last month! I read it a long time ago and it made an impression on me.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...