Oh, that connects to http://nature-of-order.stefan-lesser.com/geometry-in-software. I think many visual programming environment visions are at least partially about making more of the invisible stuff visible. But the challenge remains: software does not have to adhere to many rules of physics, chemistry, biology, which everything else in this world has to and which we have evolved to deal with.

I still fundamentally believe that there must be some equivalent of the fifteen properties for software programs. Programs certainly have structure, but it is structure of a different, more flexible kind, which is mostly unaffected by physical forces and processes in the real world.

yep 🙂

Or as I like to put it as an application programmer, "For all I know, it works by little hamsters running around underneath the keyboard." Whatever is fundamental doesn't have much to do with the hardware. And even then, the symbol systems on which computation is strongly based kind of get blurry when you head over to statistical AI land.

For those interested in digging deeper (under the keyboard to dissect these hamst… hmm… maybe let’s not go with that metaphor here…) and figuring this out, please feel invited to this little corner of the internet: http://nature-of-order.stefan-lesser.com/telegram-group

We human are custom to decompose spatially or temporally. However, the business logic is inherently spatially / temporally entangled. Decompose via interface stability is the way forward, but unnatural to newbies. Also, when conflicting business requirement accumulated to a point, no matter how you decompose it, there will be no simple solution. Hence, the benefit of doing it right is not worth the effort, so many just throw in the towel.

@taowen Would you mind explaining what you mean by "Decompose via interface stability”?

For example you are building a workbench for customer service, they need to lookup order while talking to customer on the phone. There will be a lot "tools" they need to use on that screen, but that does not mean the workbench should be written in same code repo by a single team. If the "tools" need to show what customer has ordered, or what the terms and conditions are, or allow giving coupon to compensate customers, we might find the "tools" need to be upgraded very frequently acccording to git commit history. The interface will not be stable, if workbench team need to read or write a lot of external rpc/databases. The interface will be much more stable, if the workbench team just allow other team to extend the workbench ui (contributing react component for example). It means we need to cut up the teams where the interface is stable, not just spatially or temporally.

@taowen Got it. Thanks. Duh… sorry, somehow I wasn’t able to pick this up from the initial description, but it’s pretty obvious in hindsight.