Auiag, an application generator understanding me

I read a book written by Jessica Gasiorek: "Message Processing: The Science of Creating Understanding" it is about understanding the mystery of peoples key competence: our ability to communicate and understand what people mean. In my opinion it’s a good foundation for a better understanding of the problems encountered in building and realizing information systems, digital transformation and data driven organizations.

I found the book in the references of a nice blog of Alcedo Coenen on the principles of lowcode. Made me think. Got me to this nice idea I think is worth telling. Perhaps Alcedo is gong to write about it too?

Main topic of the book is the inferential model (on communication) (Scott-Phillips, 2015; Sperber & Wilson, 1986). In this model of communication the emphasis is on understanding. It uses a different transmission paradigm, not the logistical, narrow paradigm of coding, sending, decoding. The bottom line is that - if you and I get into a situation where we communicate - I continuously assess all the things you could mean and use all the sensory perceptions I have of you, and the situation we are in, to choose the most likely. This even applies when two strangers meet on a narrow sidewalk and without words communicate whether they are going to pass each other on the left or right.

Now suppose that we use this inferential model in a situation where an artificial understanding intelligent application generator (let's call her-him Auiag) and I are in a conversation to design and build a new application. Auiag 'knows' that we are talking about an application. So 'all the things I could mean' is a subset of the space of all possible applications. Now this is a large set, countable infinite, but every element can - at least in theory- be generated. However, it's not possible to generate all elements, it's too big and it would take too much time. Now not all applications are allowed, e.g. everyone only wants secure applications. So if Auiag has a way to generate relevant applications and select the secure ones that requirement has been taken care off. Now suppose the application should also be able to register data. Again this narrows down the possible applications I could mean. Auiag has 'only' to chose from the secure, data registering applications. I hope you get the idea. Building an application is not coding, but generating the possible ones and choosing the ones that fit the requirements best. Therefore Auiag has to be able to 'generate' the possible applications I could mean and to make my requirements 'testable' to select the ones I could mean.

However, this is still a much too large task to handle. But it's also not the way we specify and build applications nowadays. We create much more smaller pieces of what is needed: use cases. A use case can be seen as a "part of behavior" the application has to be able to exhibit. If we use the same metaphor again, Auiag has to be able to generate all kinds of "application-behavior" and, in conversation with me, elicit the requirements for this "part of behavior". To do this, a grammar, i.e. a set of production rules, is needed in which every 'program', i.e. a set of sentences, describes a specific application behavior. Auiag an I are furthermore in a conversation to get the requirements clear. To understand the requirements I mean another grammar is needed, in which every 'program' is a test, testing a specific requirement.

I hope you see the fractal pattern. We need formal grammar's to be able to generate the possible solutions. Furthermore we need other formal grammar's to be able to generate the possible requirements. In these grammars our knowledge of building good secure performing understandable applications should have been made operational. Here design-patters find their ultimate form. A grammar could be as simpel as a list of possible patterns to choose from. Understanding becomes easy: which of the possible patterns do you mean? In the end it comes down to Auiag presenting me a , not too long, list of possibilities, where I have to choose one or more to be precise on what I mean.

If we want Auiag to come up with real solutions, it needs a good 'search strategy'. The space of possible solutions is very large and multi dimensional. Part of the search strategy can be found in the way we develop applications nowadays: we write use-cases, we set up conceptschemes, ontologies, datamodels, we build UI-stubs, testware, we generate POC's, etc. All this can be used to get a route from the business opportunity or business problem to the changed application landscape containing new or changed application components.

Which way to Go? Yes, I've written 'Go' not 'go'. On purpose, because the algorithms used to win that game, should be used here to win 'the understanding game'. And speaking of games, we are back with Wittgenstein. :-)

And what do you think? Is this a way to Go?

Jan Campschroer, If I were you, you could understand me better.