Nice article. I resonated particularly with the part about acquiring a larger set of ideas as it's something I've definitely noticed in my own development.
The Smalltalk story is something I experienced before several times; it reminded me of something I read once, "The only difference between you and Shakespeare is his use of idioms not vocabulary".
In other words, Shakespeare greatness comes from his broader set of ideas and the way he could compose them to produce his art, not by necessarily knowing more words.
Besides that, I want to also touch on this part - "There’s always a structure".
This is something I've believed too but recently I've been questioning that assumption.
I think it's still true for many domains and even complicated ones but after being exposed to the Complexity Sciences through Residuality Theory I'm a bit more skeptical.
As software "eats" more of the world, can we ever find structure in those ever complex and uncertain contexts?
Even if we find the structure that exists today will it be the same tomorrow?
It is true that at the end of the day we cannot escape structure since software systems must have one but can they truly represent the supposed essential structure that exists underneath?
What do you think about looking at software and the domains through that lens?
Your article somehow evokes hope ;) There actually is a domain I partially gave
up on.
Imagine a PIM holding multiple things, refering to them as "articles" and
"variants". Every size (like, t-shirt, bicycle…) is a variant linked to the
article, enums can be managed and linked cleanly from other tables and so on. An
article can exist in multiple years, so there's a link to a model year enum,
too. Whenever attributes of a model or variant change, a new model entry with
all variants gets created and tagged with years.
Now there's business needs. Your translators, shop managers etc. should not know
secret plans, thus planned articles for the future are managed in another tool.
That tool allows managers to give state to every variant of an article, where
every state other than "keep as it is for next year" will require some kind of
"splitting" the model in the PIM. Yes, that includes adding a new size to a
well-known vintage article.
Then articles are planned some years in advance. So while 2028's business is
planned, someone decides articles need to be changed from 2026 on. Someone else
later reverts that decision. Maybe from 2027. There's a wild series of
transformations, splits, merges of articles and variants, as well in the tool's
independent database as in the PIM.
While most of the syncing issues could be caught by a small rule engine, there's
so many mutually exclusive business cases causing subtle errors with the state
in the PIM - even some attributes which need to be synced but only in one
specific year (writing that down gives me an idea for another rule…). So, parts
of the system required me to open that can of paste and liberally pour it over
the codebase.
Nice article. I resonated particularly with the part about acquiring a larger set of ideas as it's something I've definitely noticed in my own development.
The Smalltalk story is something I experienced before several times; it reminded me of something I read once, "The only difference between you and Shakespeare is his use of idioms not vocabulary".
In other words, Shakespeare greatness comes from his broader set of ideas and the way he could compose them to produce his art, not by necessarily knowing more words.
Besides that, I want to also touch on this part - "There’s always a structure".
This is something I've believed too but recently I've been questioning that assumption.
I think it's still true for many domains and even complicated ones but after being exposed to the Complexity Sciences through Residuality Theory I'm a bit more skeptical.
As software "eats" more of the world, can we ever find structure in those ever complex and uncertain contexts?
Even if we find the structure that exists today will it be the same tomorrow?
It is true that at the end of the day we cannot escape structure since software systems must have one but can they truly represent the supposed essential structure that exists underneath?
What do you think about looking at software and the domains through that lens?