4 ms·

Very intriguing ideas. Is there a relationship here, with the concept of starting an application by thinking more about the data structures and getting those r

Very intriguing ideas. Is there a relationship here, with the concept of starting an application by thinking more about the data structures and getting those right, before proceeding with the rest of development? Or are you speaking of more abstract mental models?

PaulHoule 4y ago
The fancy way to think about it is https://en.wikipedia.org/wiki/Refinement_calculus https://en.wikipedia.org/wiki/Refinement_calculus That is you need to be able to think about an application at various levels of granularity. It is important, for instance, to be able to explain the business case of your application succinctly. Everybody from your devs to the salespeople need to understand this because it informs everything else they do. Above the level of data structures realized in Java classes, SQL tables, XML documents and such there is this subject https://en.wikipedia.org/wiki/Ontology https://en.wikipedia.org/wiki/Ontology which is where mental models reside. My guess is that if "low code" is going to be a reality it will require the incorporation of well-developed ontologies. For instance, there are many applications that require a customer database and even though they all have some unique requirements there are numerous things like addresses, postal codes, phone numbers, etc. To pound out high-quality applications quickly we would want to to reuse as much stuff as possible from a general ontology (offering the possibility of reusing code as well as the data structures) but still be able to customize the application as necessary while hopefully deterring people from making harmful customizations. An example of the latter is that many applications end up having one field for a contact's phone number, learn the hard way that somebody might have two phone numbers, put in a second field for the phone number, find out there could be three, ... It's highly predictable that contacts are going to have multiple phone numbers so the right thing to do is support multiple phone numbers from the beginning and do that all the way from the database to the UI. It might be fair to let specializers put on a constraint that "for now, a contact can have at most one number" but still reuse all the stuff that supports multiple phone numbers. You certainly don't need to plan out every single detail of data structure in advance, but I can say that if you do want to deliver a complex application in terms of little feature updates that are actually little, you will need to be thinking ahead about data, not so much about code.

PaulHoule 4y ago

The fancy way to think about it is https://en.wikipedia.org/wiki/Refinement_calculus https://en.wikipedia.org/wiki/Refinement_calculus That is you need to be able to think about an application at various levels of granularity. It is important, for instance, to be able to explain the business case of your application succinctly. Everybody from your devs to the salespeople need to understand this because it informs everything else they do. Above the level of data structures realized in Java classes, SQL tables, XML documents and such there is this subject https://en.wikipedia.org/wiki/Ontology https://en.wikipedia.org/wiki/Ontology which is where mental models reside. My guess is that if "low code" is going to be a reality it will require the incorporation of well-developed ontologies. For instance, there are many applications that require a customer database and even though they all have some unique requirements there are numerous things like addresses, postal codes, phone numbers, etc. To pound out high-quality applications quickly we would want to to reuse as much stuff as possible from a general ontology (offering the possibility of reusing code as well as the data structures) but still be able to customize the application as necessary while hopefully deterring people from making harmful customizations. An example of the latter is that many applications end up having one field for a contact's phone number, learn the hard way that somebody might have two phone numbers, put in a second field for the phone number, find out there could be three, ... It's highly predictable that contacts are going to have multiple phone numbers so the right thing to do is support multiple phone numbers from the beginning and do that all the way from the database to the UI. It might be fair to let specializers put on a constraint that "for now, a contact can have at most one number" but still reuse all the stuff that supports multiple phone numbers. You certainly don't need to plan out every single detail of data structure in advance, but I can say that if you do want to deliver a complex application in terms of little feature updates that are actually little, you will need to be thinking ahead about data, not so much about code.