4 ms·

From what I can tell, I've built something similar, but a bit more niche, for industrial control and safety systems. Though it lends itself to wider applicatio

From what I can tell, I've built something similar, but a bit more niche, for industrial control and safety systems. Though it lends itself to wider applications of state based behaviour. It seems semi obvious to me this avenue is the path forward, not least because of the advantages that flow from having your specification as data, rather than dots on the page from a crappy narrative. However, this approach does encounter some resistance because it is big work up front - you have to fully understand what you want to build, before you build it. It can look like little progress occurs for some time, but it all comes together much more quickly after specification is complete.

michbarsinai 2y ago
Very true. I think the upfront work required is the biggest resistance we get, along with "nah, I'm just gonna let some AI understand this for me" (can't help there, they'll have to find out for themselves :-)). We alleviate this by allowing users to add details as needed - the underlying model does not require full description of the entire system, only the parts on which the current feature depends. This reduces the upfront work required and allows adding details later, on an "as-needed" basis. But sure, some upfront work has to be done. Another resistance I sometimes get is that "people just don't think this way" or "I don't have anyone in the team that can understand the product AND the QA side". Did you get these too?
- airbreather 2y ago
  And worse, right through to experienced engineers telling me that I couldn't possibly specify all functionality this way, because the basic axioms are so small and few in number. But when I have managed to implement this way, the amount of pain that does not appear in later stages of deployment is startling. I have a uniquely frugal algorithm for execution of the state tables I generate, reduces down to a handful of logic operations, DM me if you are interested to discuss.
  - michbarsinai 2y ago
    Email sent to mail at profile :-)

michbarsinai 2y ago

Very true. I think the upfront work required is the biggest resistance we get, along with "nah, I'm just gonna let some AI understand this for me" (can't help there, they'll have to find out for themselves :-)). We alleviate this by allowing users to add details as needed - the underlying model does not require full description of the entire system, only the parts on which the current feature depends. This reduces the upfront work required and allows adding details later, on an "as-needed" basis. But sure, some upfront work has to be done. Another resistance I sometimes get is that "people just don't think this way" or "I don't have anyone in the team that can understand the product AND the QA side". Did you get these too?

airbreather 2y ago
And worse, right through to experienced engineers telling me that I couldn't possibly specify all functionality this way, because the basic axioms are so small and few in number. But when I have managed to implement this way, the amount of pain that does not appear in later stages of deployment is startling. I have a uniquely frugal algorithm for execution of the state tables I generate, reduces down to a handful of logic operations, DM me if you are interested to discuss.
- michbarsinai 2y ago
  Email sent to mail at profile :-)